VOResource 1.1: relationship type vocabulary

[Markus Demleitner]

Dear Colleagues,

For reference: we're talking about 
http://docs.g-vo.org/vocab-test/relationship_type/2016-08-17/relationship_type.html

On Fri, Sep 23, 2016 at 04:18:29PM -0400, Accomazzi, Alberto wrote:
> On Thu, Sep 22, 2016 at 4:58 PM, Mireille Louys <mireille.louys at unistra.fr>
> wrote:
> > (1) style mixture.  I have kept the classic VOResource terms
> > (served-by, related-to, etc), and I think we have to do that as these
> > terms are in active use.  I have, however, taken over the DataCite
> > terms that I could see some use for in the VO. These use CamelCase.
> > I readily admit that's ugly and potentially annoying since resource
> > authors will always have to remember which style a specific term
> > uses.  If you really can't stand it, I see two alternatives:
> >
> >   a) Go all the way to DataCite style.  This breaks some VO
> >   infrastructure, enough to make me reject that for a 1.1 release
> >
> >   b) Change DataCite terms into the legacy VOResource 1.0 style
> >   (is-supplement-to, etc).  That'd make things somewhat harder for
> >   VOResource->DataCite translators, but I could live with that.  If
> >   people speak out for this, I'd do it.
> >
> > I would prefer an homogeneous vocabulary . So option b) gets my preference
> > .
> I also have a slight preference for option b).  And I don't think having to
> go to a v.2 (rather than 1.1) is a huge burden, but people who are directly
> affected by the change should speak up!

Well, right now, for instance TOPCAT uses the literal string
'served-by'; were we to write 'servedBy' in the future, it would have
to use both forms for a while, and current versions of TOPCAT would
at some point fail.  This piece of code is not yet critical, but I
take this as an indication that it's preferable not to touch the
relationship terms.

So: does anyone actually want to champion (a) -- camel-case the
existing terms?

Since we have two votes for a homogeneous style, does someone
seriously object to (b), transforming DataCite terms by going from
IsSupplementTo to is-supplement-to?  In case there's lawyers present:
The rule would be (uniformly for all terms borrowed from camel-cased
sources): "replace each internal upper case letter with a sequence of
'-' and that letter lowercases, then lowercase the entire term"?  

> Terms in DataCite that I think won't serve forseeable discovery use
> > cases and that I hence didn't include in the vocabulary:
> >
> > IsCitedBy  HasMetadata  IsMetadataFor  IsReferencedBy  References
> > IsDocumentedBy Documents   IsCompiledBy  Compiles   IsVariantFormOf
> > IsOriginalFormOf   IsIdenticalTo IsReviewedBy Reviews IsDerivedFrom
> > IsSourceOf
> >
> > Do you disagree with my selection?
> >
> >
> I'd include IsDerivedFrom and IsSourceOf (see below).

IsDerivedFrom collides with VOResource 1.1 derived-from.  I don't
think anyone does anything sensible with derived-from at this point,
so we could deprecate it (there's a mechanism for that I'll discuss
in a later mailing on date_role) and just use is-derived-from.  Is
that what you're asking for here?

You comment on IsSourceOf I didn't understand -- it's already in, no?

> > (c) I'm not including IsDerivedFrom (which is about the same as our
> > derived-from) from the DataCite vocabulary since I expect that here,
> > the two term sets will live together for quite a while, and I don't
> > want to deprecate one in favour of the other.  Should we?  The reason
> > for the co-existence is that I don't think DataCite will talk about
> > services any time soon, and so the very important served-by
> > relationship may not enter DataCite for quite a while.
> >
> Call me naive, but I would suggest that getting our needed relationships
> into DataCite's schema should be an achievable goal.  I just noticed that
> version 4.0 came with some additional elements (none too interesting for
> us), which indicates that the working group is quite active and (based on
> what I observed) open to consider use cases  -- after all we got bibcodes
> in there as a recognized identifier scheme.  So I would consider it a
> success if we could minimize VO-specific terms in favor of Dublin Core or
> DataCite ones going forward.  And getting our terms into those standards
> would be the path to it.

The two terms not really covered by DataCite are served-by and
service-for.  On mirror-of see below, on derived-from see above, on
related-to... ah well.  It's in use pretty widely (there are 164 such
relations in today's Registry), but I'm not convinced it's terribly
useful.  And in those cases it is useful, perhaps one of the new
DataCite terms might work.

So -- does anyone here easy access to people involved with the
DataCite schema and can sound out how they feel about (for them)
ServedBy and ServiceFor?

       -- Markus