<div dir="ltr"><div class="gmail_default" style="font-size:small">One of the ideas we discussed at the interop was for the contentType to cover both level 0 and 1 Of Ada's very useful list above. We already do this with Datalink itself via a param in the type:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">application/x-votable+xml;content=datalink</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The idea was to prototype using the ObsCore dataproduct_type values with the content param, which works quite nicely for several of the types and tells you alot more than the bare mime type, eg:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">application/fits</div><div class="gmail_default" style="font-size:small">application/fits;content=image<br></div><div class="gmail_default" style="font-size:small">application/fits;content=spectrum</div><div class="gmail_default" style="font-size:small">image/png;content=spectrum along with semantics=#preview??<br></div><div class="gmail_default" style="font-size:small">application/x-votable+xml;content=spectrum</div><div class="gmail_default" style="font-size:small">application/x-votable+xml;content=datalink</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We could eventually sanction and give guidance for this sort of usage and I think it is something simple that could be used by the larger community. The thing is that services can do this now: in a DataLink links resource, in HTTP Content-Type headers, in VOSpace node metadata, etc... all allowed now and all adding more useful information for clients to act on... the usefulness of this idea beyond the links response is appealing and makes me not want a DataLink-specific solution (new field).<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">thoughts?</div><div class="gmail_default" style="font-size:small"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 9 Dec 2019 at 01:31, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi DAL, again,<br>
<br>
On Fri, Dec 06, 2019 at 02:45:30PM +0100, ada nebot wrote:<br>
> But if were to add terms such as sibling and so on, there is already an IVOA relationship vocabulary: <br>
> <a href="http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html" rel="noreferrer" target="_blank">http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html</a> <<a href="http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html" rel="noreferrer" target="_blank">http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html</a>><br>
> <br>
> Comments? <br>
<br>
This is an excellent point. relationship_type currently reflects the<br>
parts of DataCite's relationships relevant to VOResource. But these<br>
relationships by DataCite's goals are also (indeed, mainly) intended<br>
for what we in the VO would call datasets. And that happens to be<br>
rather close to what Datalink is talking about.<br>
<br>
I also agree it looks a bit odd that we have #IsDerivedFrom and <br>
#IsSourceOf in relationship_type and #progenitor and #derivation in<br>
datalink/core -- it's one of these cases where things that appear to<br>
be largely unrelated (Registry and Datalink) suddenly turn out to<br>
have rather close relations after all.<br>
<br>
On the other hand, of course, I'm always for pragmatism when in<br>
doubt. The main use case for Datalink semantics has been (or so I<br>
think) to let clients filter out or group links depending on what<br>
they perceive the current user interest (which I think so far none<br>
do): Hide #progenitor in science analysis, hide #derivation during<br>
debugging.<br>
<br>
For that, #progenitor and #derivation would, I think, work rather<br>
well (though I'm suddenly not sure any more why #calibration isn't a<br>
child of #progenitor -- if someone puts in a VEP for that, I think<br>
you'd have my vote). And anyway, before we embark on a re-design of<br>
that part of datalink with a view to unifying it with VOResource, I'd<br>
frankly like to have opinions from datalink consumers if they'd like<br>
a move towards relationship_type.<br>
<br>
So, I guess what I'm saying is: as long as we have #derivation and<br>
#progenitor in datalink/core, there should be #sibling. This at<br>
least appears attractive to me from a producer side (which, yes,<br>
isn't more than half the picture).<br>
<br>
The alternative would be to deprecate #derivation and #progenitor and<br>
devise some way to pull relationship_type into Datalink. I give you<br>
that'd certainly be cleaner. But, as said above, my<br>
pragmatism-o-meter currently has an underflow when considering that.<br>
But, again, it's been known to be off before.<br>
<br>
-- Markus<br>
<br>
<br>
PS: Incidentally, vocabularies should be cited with the namespaces<br>
given on their HTML renditions, in this case<br>
<a href="http://www.ivoa.net/rdf/voresource/relationship_type" rel="noreferrer" target="_blank">http://www.ivoa.net/rdf/voresource/relationship_type</a> and<br>
<a href="http://www.ivoa.net/rdf/datalink/core" rel="noreferrer" target="_blank">http://www.ivoa.net/rdf/datalink/core</a>. I wonder if there's a good<br>
way to encourage people to not just yank the URL out of their<br>
browser...<br>
</blockquote></div>