Foreign relations [was: VOResource 1.1 RFC]

Sarah Weissman sweissman at
Thu Jun 8 16:15:46 CEST 2017

Thanks for your reply, Markus.

From: <registry-bounces at> on behalf of Markus Demleitner msdemlei at<mailto:msdemlei at>

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?]

I see your point about not wanting to complicate the existing vr:relationship type. I think adding another relationship could also be confusing, since then implementers would have to understand when to use one over the other and people using the data would have to make a separate query to another table to find all of the possible relations. I do not know which is more confusing. Of course it would also confusing and error-prone to change the attributes in vr:relationship and to make everyone update their data to reflect this.

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.

I agree that this should be driven by use cases, and I do not have a use case now. This was more of an observation based on my experience trying to express things in DataCite. If others have possible use cases that would be supported by an expanded concept of relationship in the VOResource schema I hope they will share them.

Thanks again,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the registry mailing list