Foreign relations [was: VOResource 1.1 RFC]

[Markus Demleitner]

Hi Sarah,

On Wed, Jun 07, 2017 at 06:22:56PM +0000, Sarah Weissman wrote:
> I think what I'm unclear about is whether vr:relationship and
> relatedResource is intended to refer only to resources with an IVOA
> ID. There doesn't appear to be a way to use vr:relationship to

Well, @ivo-id is optional, and indeed there are a lot of
relationships defined without @ivo-id in the current VO[1], so in
principle you can declare relationships to non-registred things.

There's even cases where that may make sense.  For instance, we don't
register software (yet?), so a tutorial that wants to be discoverable
as "using" TOPCAT would currently just say

     <relationship>
       <relationshipType>Cites</relationshipType>
       <relatedResource>TOPCAT</relatedResource>
     </relationship>

-- and there'd be a good chance that someone looking for TOPCAT
tutorials could actually find them.  I give you that's a relatively
remote use case.

> (some put the IVOA ID as the value of relatedResource instead of in
> the ivo-id attribute).

This is wrong -- perhaps it would be a good idea to send out a bunch
of mails asking the people who actually do this to fix things[2].

> with vr:relationship and I'm not sure what the best way is to do
> this. In theory I can do the following:
> 
>     <relationship>
>       <relationshipType>HasPart</relationshipType>
>       <relatedResource >doi:10.5071/FK12345</relatedResource>
>     </relationship>
> 
> but since vr:ResourceName is supposed to be the name of a
> potentially registered resource, this seems incorrect, since
> "doi:10.5071/FK12345" is not the name of a resource, but an
> identifier. And referring to a related resource by just a name

Exactly.  *If* we expect a machine to do anything sensible with
non-Registry relationships, we can't lie to it, and we'll have to say
a relatedIdentifier is an identifier, not a name.

Doing it as proposed by Sarah:

> would need to look something like this:
> 
>     <relationship>
>       <relationshipType>HasPart</relationshipType>
>       <relatedResource resourceIdentifierType="DOI"
>       resourceIdentifier="doi:10.5071/FK12345">My related Resource</relatedResource>
>     </relationship>

...would do the trick.

I'm not altogether sure we actually want to do it like this, though;
in the end, that depends what we want to do with this kind of
information.

I'll voluteer my perspective right here, starting from the question:
Should this end up in RegTAP's relationship table, and if so, where?

My first feeling is: I don't want it in rr.relationship; my reasoning
is that rr.relationship should be kept as simple and uncluttered as
possible since queries through it are hairy enough (I've said a bit
about it in
http://wiki.ivoa.net/internal/IVOA/InterOpOct2014Reg/datacolls.pdf).

In other words: the pattern

  SELECT lres.ivoid, relationship_type, rres.ivoid
  FROM rr.resource as lres
    NAURAL JOIN rr.relationship
    JOIN rr.resource as rres
      ON (rres.ivoid=related_id)

should have as few pitfalls as possible.  By definition, external
identifiers can't possibly work in this pattern, so as long as that's
what "we" think that's what rr.relationship is primarily for, I'd say
external relationships shouldn't go in there.

>From there, I'd go back to VOResource, and since the content model of
external relationships is quite different from existing
relatedResource anyway -- no @ivo-id (right?), instead (probably)
relatedIdentifierType --, I'm tempted to say: "Why not have an extra
type and perhaps an extra element?"  [foreignRelation?]

But either way, I'm not convinced yet that there are sufficiently
strong use cases to justify a new element or changing
relatedResource.  After all, if we put in a feature, this brings with
it the implicit expectation that our clients will do something with
it, and that may be an extra challenge when you introduce lots of
different identifier types.  

>From that perspective, perhaps it's easier to make it possible to
pull the "foreign" resources into the Registry?

      -- Markus


[1] select count(*) from rr.relationship where related_id is NULL
gives 186 at this point.

select relationship_type, count(*) as n 
from rr.relationship 
where related_id is NULL
group by relationship_type

shows that 75 of these are service-for (which could make sense,
actually; the 9 served-by are almost certainly bogus).  71 are
related-to, 29 are already cites (without having checked, I'd guess
these are the tools declarations of tutorials).

[2] Ahem.  Turns out I was one of them -- hurry with this query:

select distinct role_name, email from rr.res_role
natural join rr.relationship
where base_role='contact'
and related_name like 'ivo://%'

to see me in the list of sinners before the fixed record is being
picked up:-)

Well, if you're in there, too, would you fix your records?