VOResource 1.1: relationship type vocabulary

Mon Sep 26 17:45:22 CEST 2016

Hi Markus et al,

On Mon, Sep 26, 2016 at 5:32 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

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

I apologize, I now realize that I misspoke when I said my preference was
b), I intended to "vote" for using the DataCite style if going for a v.2 of
the standard.

Your point about breaking TOPCAT and possibly other applications is a
concern.  Presumably clients to use schema-aware logic to be tolerant in
what they get from a service, but obviously an older version of TOPCAT
wouldn't know what to do with a VOResource v.2 record.

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

So if we go for a v.2 document then I don't see a reason why we should
"translate" CamelCase to dash-case(?).
So the only reason to stick with the current style IMHO is so we can keep
the standard in the 1.x series.

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

Yes, I misunderstood your intent (I thought you wanted to get rid of both),
so we're good.

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

I met a couple of these people over the years and can ask for their
reaction about adding these relationships but as you can imagine these
decisions take time and consensus to make so it's going to be a long time
before (and several discussions on mailing lists) before these things may
come to fruition.  Still, if nobody else volunteers and if we think this is
a good direction for us to move in, I'm happy to inquire.

-- Alberto

-- 
Dr. Alberto Accomazzi
Principal Investigator
NASA Astrophysics Data System - http://ads.harvard.edu
Harvard-Smithsonian Center for Astrophysics - http://www.cfa.harvard.edu
60 Garden St, MS 83, Cambridge, MA 02138, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160926/bfc02f1c/attachment.html>