[VEP-003]: datalink/core#sibling

[ada nebot]

Hi All, 

As I see it, the things we are discussing concerning Datalink fall into 4 independent levels or categories: 
Level 0 - Data-format (fits, VOTable, PDF, png, …)
Level 1 - Data-type (tabular, image, spectrum, cube, text, …)
Level 2 - Data-information (Documentation, Calibration, Log, Preview, …)
Level 3 - Data-relation (Derived from, Progenitor of, Sibling of, ...)

I see these as orthogonal levels since a **list of links** can be of any type (level 1) with any kind of format (level 0), 
any kind of relation (level 3) and could have any type of associated information to describe it (level 2).   

Today the list of links returned by datalink is described in the columns content-type and semantics. 
These two columns cover the above levels only up to some degree.   
- Content-type: covers level 0 mainly, with some exceptions such as VOTable (which is also level 1). 
- Semantics: covers level 2 mainly (e.g. preview), but also level 3 (e.g. derivation, progenitor). 

Datalink at the moment has no field properly covering level 1 and applications (—> users) would benefit from having that well covered. 

So, in my opinion, if I had to redo Datalink I would keep these different levels separated instead of putting everything into the semantics field. 
But applications might have a different point of view here —> Shouldn't we add Apps to this discussion? 

Timeseries would be in level 3, since it is a relation. And I don’t think we would need the use of sibling or progenitor or anything like that for timeseries. 
What we need is to be able to say is: 
- This list of links are timeseries of tabular type 
- This list of links are timeseries of spectrum type
…

But if were to add terms such as sibling and so on, there is already an IVOA relationship vocabulary: 
http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html <http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html>

Comments? 

Cheers,
Ada


--
Astronome Adjointe
CDS, Observatoire Astronomique de Strasbourg (ObAS)
UMR 7550 Universite de Strasbourg 
11, rue de l'Universite, F-67000 Strasbourg

> On 6 Dec 2019, at 11:27, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear DAL, dear Semantics,
> 
> Following the discussions on VEP-001, its author François agreed to
> first try with a VEP that only has the core term and to defer the
> child terms intended for SAMP resolution until we've investigated
> alternative solutions for that requirement in datalink.  Also, Pat's
> remark that all data in a datalink document better be "associated"
> suggested a change of terms.
> 
> Therefore, we've retired VEP-001 (there's a discussion of the details
> in
> https://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-001.txt).
> 
> Instead, there's now VEP-003:
> 
> ocabulary: http://ivoa.net/rdf/datalink/core
> Author: François Bonnarel, Markus Demleitner, msdemlei at ari.uni-heidelberg.de
> Date: 2019-12-06
> Supercedes: VEP-001
> 
> New Term: sibling
> Action: Addition
> Label: Sibling Data
> Description: Data products derived from the same progenitor as #this.
>  This could be a lightcure for an object catalog derived from repeated
>  observations, the dataset processed using a different pipeline, or the
>  like.
> Used-in: 
>  http://dc.g-vo.org/gaia/q2/tsdl/dlmeta?ID=ivo://org.gavo.dc/~?gaia/q2/199286482883072/BP
>  This is GAVO's rendition of the Gaia DR2 epoch photometry, where
>  users retrieve a time series in a specific band; the time series
>  in the other bands are the siblings of that.
> 
> Rationale: 
>  It is fairly common in complex pipelines that multiple data products
>  result from a single observation.  Often, this is true even in a
>  single pipeline step, and hence the data products are not in a
>  progenitor-derivation relationship.  Still, researchers will want to
>  know about these data products; for instance, while exploring a source
>  in Gaia, a quick way to access epoch photometry or the RP/BP spectra
>  is obviously valuable; such artefacts are not really progenitors of
>  the catalog entry, though.  In such cases, #sibling (or perhaps one of
>  its future child terms) should be used.
> 
>  Clients should offer #sibling links in a context of scientific
>  exploitation of the dataset (as opposed to, say, debugging).
> 
> 
> Opinions?  Comments?  
> 
> I'd suggest to keep this discusson on the DAL list.
> 
> Thanks,
> 
>           Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20191206/5556b704/attachment.html>