Datalink vocabulary extension: sibling/co-generated

[Paul Harrison]

Hi,


> On 2020-05 -07, at 10:58, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> But: before I put in #co-generated into my service and thus make
> François' proposal for VEP-004 valid and publishable: Pat, what
> you're saying is you would not like the proposed description:
> 
>  Data products derived from the same progenitor as #this.  This
>  could be a light-curve for an object catalog derived from repeated
>  observations, the dataset processed using a different pipeline, or
>  the like.
> 
> for #co-generated?  And how much would you dislike it? [as in: enough
> to block the VEP?  Because then I'd probably save the time until
> we're closer to consensus or someone else goes ahead with
> #co-generated]
> 

It strikes me that as finding the correct term is proving so difficult then it is indeed the description/concept that is the problem, and perhaps it should be dropped entirely - I get the feeling that what is is actually desired to be expressed in several of these use cases is beginning to move into provenance DM territory.

I always like to keep things simple and imagine what a fairly dumb client is going to do with the information to further process it rather than what a human looking at the pointed to information can do, and I generally think that in many cases you cannot really do better than “related” - Markus had said something similar earlier in the thread


> #see-also -- the idea is that it's "data people might be interested
> in when looking at #this".  The trouble is that once I try to have a
> clear definition for what this actually means I fail.  You see,
> essentially all datalink terms would fall under #see-also, and I
> couldn't find a good criterion to exclude them.
> 
> So, if we do something along the lines see-also, it would have to be
> see-also-if-X, where X could be,  perhaps, "scientifically exploiting
> #this" or "you have found something interesting in #this and would
> like to learn more about it" or whatever.  I think you'll agree that
> these proposals are...unconvincing.

I think that the above is the concept that most people in this thread would like to try to express in all the varied ways that the use cases have shown, and that is clearly not a single vocabulary term, but possibly a whole ontology.

> 
> After this, I'm essentially back to #sibling, which is well-defined
> and (IMHO) easy to explain, which, as concepts go, is great.  It's
> also been useful *for publishing* in several other data collection,
> such as when people did line maps for a spectral cube.

in the 'family tree' of relationships, the ”interesting" linked data might be a cousin/uncle etc. - so this is where I come to a different conclusion about all the contradictions that occur when a particular choice is made - just drop the concept.

Because linking is a very powerful tool, there is a tendency to want to put in lots of links,  but can you be sure that you are presenting a “complete” set of links. The IVOA has a whole lot of “discovery” protocols which are in competition with these “hard” links, and in particular with this “sibling concept” - if my original search did not tell me about these siblings why is datalink trying to tell me? If I am really interested in (otherwise only loosely related) things that have come from the same progenitor, then I think I should be looking at provenance DM information.

Regards,

Paul.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20200511/bfea40bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20200511/bfea40bd/attachment.p7s>