[VEP-003]: datalink/core#sibling

[Patrick Dowler]

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:

application/x-votable+xml;content=datalink

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:

application/fits
application/fits;content=image
application/fits;content=spectrum
image/png;content=spectrum along with semantics=#preview??
application/x-votable+xml;content=spectrum
application/x-votable+xml;content=datalink

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).

thoughts?

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 9 Dec 2019 at 01:31, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi DAL, again,
>
> On Fri, Dec 06, 2019 at 02:45:30PM +0100, ada nebot wrote:
> > 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?
>
> This is an excellent point.  relationship_type currently reflects the
> parts of DataCite's relationships relevant to VOResource.  But these
> relationships by DataCite's goals are also (indeed, mainly) intended
> for what we in the VO would call datasets.  And that happens to be
> rather close to what Datalink is talking about.
>
> I also agree it looks a bit odd that we have #IsDerivedFrom and
> #IsSourceOf in relationship_type and #progenitor and #derivation in
> datalink/core -- it's one of these cases where things that appear to
> be largely unrelated (Registry and Datalink) suddenly turn out to
> have rather close relations after all.
>
> On the other hand, of course, I'm always for pragmatism when in
> doubt.  The main use case for Datalink semantics has been (or so I
> think) to let clients filter out or group links depending on what
> they perceive the current user interest (which I think so far none
> do): Hide #progenitor in science analysis, hide #derivation during
> debugging.
>
> For that, #progenitor and #derivation would, I think, work rather
> well (though I'm suddenly not sure any more why #calibration isn't a
> child of #progenitor -- if someone puts in a VEP for that, I think
> you'd have my vote).  And anyway, before we embark on a re-design of
> that part of datalink with a view to unifying it with VOResource, I'd
> frankly like to have opinions from datalink consumers if they'd like
> a move towards relationship_type.
>
> So, I guess what I'm saying is: as long as we have #derivation and
> #progenitor in datalink/core, there should be #sibling.  This at
> least appears attractive to me from a producer side (which, yes,
> isn't more than half the picture).
>
> The alternative would be to deprecate #derivation and #progenitor and
> devise some way to pull relationship_type into Datalink.  I give you
> that'd certainly be cleaner.  But, as said above, my
> pragmatism-o-meter currently has an underflow when considering that.
> But, again, it's been known to be off before.
>
>         -- Markus
>
>
> PS: Incidentally, vocabularies should be cited with the namespaces
> given on their HTML renditions, in this case
> http://www.ivoa.net/rdf/voresource/relationship_type and
> http://www.ivoa.net/rdf/datalink/core.  I wonder if there's a good
> way to encourage people to not just yank the URL out of their
> browser...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20191209/12f0d4e4/attachment.html>