VEP-015: relationship_type#References

[Markus Demleitner]

Dear Gilles,

On Fri, Mar 22, 2024 at 03:44:25PM +0100, gilles landais wrote:
> In a perfect world, qualifying the relations would be better. In practice, 
> it is not a metadata that we can provide yet (VizieR built a database in a 
> workflow existing from decades).
> That's why rdfs:seeAlso (Baptiste proposal) is exactly what we expect for
> VizieR.

As I said, rdfs:seeAlso as it is doesn't work in our context, not as
such: You can't just use any resource, not even just any property, in
our vocabularies.  We want our vocabularies to be usable without any
deeper knowledge of RDF, and already understanding what "rdfs:" here
means requires quite a bit of RDF lore, not to mention several metric
tons of code.

Now, womething like *#Unspecified as a term in relationship_type that
is wider than all the others in there we could add, but frankly such
a thing sets off all my alarms for concept we will regret on grounds
of them making the lives of our users harder rather than easier.  You
see:

> The graph you propose (PropX) is a (frequent) relation in VizieR. I told
> about that in a previous mail - however, it is is one among others (and not
> always well flagged in VizieR metadata yet).
> Furthermore, this PropX relation sounds too exotic  - I prefer generic links!

...that's your perspective as a data provider.

The data consumer, on the other hand, will prefer well-defined
metadata.  They'll want to know what to do with a link, when to use it
to do what, at the very least how to present it to their users.
If, on the other hand, all they have from the data provider is "aw,
there's *some* relationship here", it's *very* hard to make
meaningful use of that.  Me, I'd be at a loss.

Hence, I'm starting to lean towards just keep using the deprecated
#related-to for what you have used it for so far. It nicely
documents that here's historical practice that we would *want* to
migrate away from if we find a way to make this more useful to the
consumers.

Meanwhile we ought to watch what problems this whole thing (ought to)
solve(s).  If we have a bunch of phrases like...

  "If you encounter a related-to/PropWhatever link, show it like this..."

  "To find X, follow the related-to/PropWhatever link and..."

...I think we'll be in a much better situation to find (a) which
problem(s) we are trying to solve and (b) what good concept(s) might
solve them.

Thanks,

            Markus