DataCite relationships [was: VOResource 1.1 RFC]

[Markus Demleitner]

Hi Sarah,

On Wed, Jun 07, 2017 at 02:54:58PM +0000, Sarah Weissman wrote:
> My comment is about the connections between DataCite and the new
> VOResource schema. Is the goal that one should be possible to map
> between the two standards? One limitation that I have noticed with

Since DataCite doesn't know about our capabilities and tablesets,
mapping DataCite to VOResource isn't possible (in a meaningful way).
Turning VOResource into DataCite records, on the other hand,
definitiely is a design goal.  I've actually already written an XSLT
for that:

https://volute.g-vo.org/svn/trunk/projects/registry/dois/vor-to-doi.xslt

(see also the README in that directory, as well as my Trieste talk on
re-usable resources for bridging VOResource and DataCite,
http://wiki.ivoa.net/internal/IVOA/InterOpOct2016Registry/doiresource.pdf).

> DataCite and compatibility with astronomy data resources is with
> the relatedIdentifiers type. In DataCite, a relatedIdentifier must
> have a relatedIdentifierType associated with it, which come from a
> fixed list. In VOResource there is the vr:relationship type, which
> has a relatedResource element that appears to always be a
> vr:ResourceName, which as I understand it is always an IVOA
> identifier URI. This represents an incompatibility with DataCite in

Well, it's primarily a human-readable designation, but it can have an
associated IVOID, which indeed it probably always should if the
relation is intended to be "actionable" (e.g., ServedBy for dependent
resources, or perhaps Cites to discover Tutorials using some data
collection).

> two ways. One, an IVOA identifier URI is not one of the types in
> the relatedIdentifierType enumeration in DataCite. Two, DataCite
> allows a wider range of types of identifiers that may be related to
> the current described resource. Has there been any thought of
> trying to get astronomy-specific identifier types into the allowed
> list for DataCite or of expanding the types of identifiers that can
> be specified as a relatedResource for the vr:relationship type in
> the VOResource schema?

Not really; the main issue was how IVOIDs would go into DataCite
documents.  The current resolution is to use DataCite's URI type
rather than try to get a special relatedIdentifierType; I'm not 100%
convinced that's the right thing to do, but technically it's fine
because you can work out it's an IVOID based on the URI scheme.

But admittedly, if you want to build your DataCite records from
VOResource and there's DataCite metadata without correspondence in
VOResource, that's certainly an indication that we *might* need to
further expand VOResource.

> We have run into this issue with DataCite with our new DOI service
> at MAST, where we would like to put CAOM observation IDs into the
> relatedIdentifiers list, and there is not an obvious way to do
> this, but I imagine this could be an issue for anyone who is trying
> to translate between any type of astronomy resource metadata and
> DataCite.

Hm... at first glance, I'm not immediately enthusiatic about that
particular use case.  From 30000 feet, I'd say that talking about
concrete data sets is not exactly in scope for the registry, and I'd
guess CAOM obsIds would be for an individual data set, right?

Of course, once you get a bit closer, things start to look a bit
different; true, an object catalog might want to reference a data set
as a source, and when you register HiPSes, the distinction between
data set and data collection becomes somewhat blurry as well.

So, while in general I'd like to have as few features in any given
standard as possible, I see two potential use cases for extending
vr:RelatedIdentifier towards full coverage of DataCite's relations:

(a) Generate essentially arbitrary DataCite records from VOResource
records

(b) Light provenance-type relationship annotations for resources
generated from a single or some very few individual data sets.

At this point I feel these are too weak to justify extra features,
but I might be persuaded I'm wrong.

Do you think you could come up with some changes to the VOResource
schema so it would work for what you're trying to do?

         -- Markus