<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi All, <div class=""><br class=""></div><div class=""><div class="">As I see it, the things we are discussing concerning Datalink fall into 4 independent levels or categories: </div><div class=""><div>Level 0 - Data-format (fits, VOTable, PDF, png, …)</div><div>Level 1 - Data-type (tabular, image, spectrum, cube, text, …)<br class="">Level 2 - Data-information (Documentation, Calibration, Log, Preview, …)</div><div>Level 3 - Data-relation (Derived from, Progenitor of, Sibling of, ...)</div><div><br class=""></div><div><div>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), </div><div>any kind of relation (level 3) and could have any type of associated information to describe it (level 2). </div><div class=""><br class=""></div></div><div>Today the list of links returned by datalink is described in the columns content-type and semantics. </div><div>These two columns cover the above levels only up to some degree. </div><div>- Content-type: covers level 0 mainly, with some exceptions such as VOTable (which is also level 1). <br class="">- Semantics: covers level 2 mainly (e.g. preview), but also level 3 (e.g. derivation, progenitor). </div><div><br class=""></div><div>Datalink at the moment has no field properly covering level 1 and applications (—> users) would benefit from having that well covered. </div><div><br class=""></div><div>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. </div><div>But applications might have a different point of view here —> Shouldn't we add Apps to this discussion? </div><div><br class=""></div><div>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. </div><div>What we need is to be able to say is: </div><div>- This list of links are timeseries of tabular type </div><div>- This list of links are timeseries of spectrum type</div><div>…</div><div><br class=""></div><div>But if were to add terms such as sibling and so on, there is already an IVOA relationship vocabulary: </div><div><a href="http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html" class="">http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html</a></div><div><br class=""></div><div>Comments? </div><div><br class=""></div><div>Cheers,</div><div>Ada</div><div><br class=""></div><div><br class=""></div></div><div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">--<br class="">Astronome Adjointe<br class="">CDS, Observatoire Astronomique de Strasbourg (ObAS)<br class="">UMR 7550 Universite de Strasbourg <br class="">11, rue de l'Universite, F-67000 Strasbourg<br class=""></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 6 Dec 2019, at 11:27, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear DAL, dear Semantics,<br class=""><br class="">Following the discussions on VEP-001, its author François agreed to<br class="">first try with a VEP that only has the core term and to defer the<br class="">child terms intended for SAMP resolution until we've investigated<br class="">alternative solutions for that requirement in datalink. Also, Pat's<br class="">remark that all data in a datalink document better be "associated"<br class="">suggested a change of terms.<br class=""><br class="">Therefore, we've retired VEP-001 (there's a discussion of the details<br class="">in<br class=""><a href="https://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-001.txt" class="">https://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-001.txt</a>).<br class=""><br class="">Instead, there's now VEP-003:<br class=""><br class="">ocabulary: <a href="http://ivoa.net/rdf/datalink/core" class="">http://ivoa.net/rdf/datalink/core</a><br class="">Author: François Bonnarel, Markus Demleitner, <a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a><br class="">Date: 2019-12-06<br class="">Supercedes: VEP-001<br class=""><br class="">New Term: sibling<br class="">Action: Addition<br class="">Label: Sibling Data<br class="">Description: Data products derived from the same progenitor as #this.<br class=""> This could be a lightcure for an object catalog derived from repeated<br class=""> observations, the dataset processed using a different pipeline, or the<br class=""> like.<br class="">Used-in: <br class=""> <a href="http://dc.g-vo.org/gaia/q2/tsdl/dlmeta?ID=ivo://org.gavo.dc/~?gaia/q2/199286482883072/BP" class="">http://dc.g-vo.org/gaia/q2/tsdl/dlmeta?ID=ivo://org.gavo.dc/~?gaia/q2/199286482883072/BP</a><br class=""> This is GAVO's rendition of the Gaia DR2 epoch photometry, where<br class=""> users retrieve a time series in a specific band; the time series<br class=""> in the other bands are the siblings of that.<br class=""><br class="">Rationale: <br class=""> It is fairly common in complex pipelines that multiple data products<br class=""> result from a single observation. Often, this is true even in a<br class=""> single pipeline step, and hence the data products are not in a<br class=""> progenitor-derivation relationship. Still, researchers will want to<br class=""> know about these data products; for instance, while exploring a source<br class=""> in Gaia, a quick way to access epoch photometry or the RP/BP spectra<br class=""> is obviously valuable; such artefacts are not really progenitors of<br class=""> the catalog entry, though. In such cases, #sibling (or perhaps one of<br class=""> its future child terms) should be used.<br class=""><br class=""> Clients should offer #sibling links in a context of scientific<br class=""> exploitation of the dataset (as opposed to, say, debugging).<br class=""><br class=""><br class="">Opinions? Comments? <br class=""><br class="">I'd suggest to keep this discusson on the DAL list.<br class=""><br class="">Thanks,<br class=""><br class=""> Markus<br class=""></div></div></blockquote></div><br class=""></div></body></html>