VOResource 1.1: relationship type vocabulary

[Markus Demleitner]

Dear Registry,

On Mon, Sep 26, 2016 at 11:45:22AM -0400, Accomazzi, Alberto wrote:
> On Mon, Sep 26, 2016 at 5:32 AM, Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> wrote:
> > > >   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.

I'm not sure I understand the point about schema-awareness -- does
that refer to relationships within the vocabularies?  Frankly, I
don't think many clients will use any time soon, and I'm pretty sure
we should be planning for string comparisons between these terms
being prevalent for a long, long time to come -- not the least
because the dominant mode for using them will be comparisons within
ADQL queries (that's what RegTAP is about).

While, when we actually have use cases, we could add semantic
knowledge to RegTAP and friends using user defined functions, I'd be
reluctant to do that for purely cosmetic reasons.

So, I suggest we assume for the moment that clients will *not* in
general access any semantic resources when working with the
vocabularies we're discussing here.

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

-- which is IMHO a strong reason.  If I am to break stuff -- and that's
what changing the major version number is about -- I think I'd like a
strong agenda of the type "here's what we really cannot do without
breaking something." Uniform syntax of vocabulary terms in itself is,
I think, not strong enough for me.  

Conformance to an external standard might be; but since it's not
really hard to translate between the two term styles (SomeWords vs.
some-words) automatically, I'd argue that with plan (b) we'd be
following the external standard for almost all intents and purposes.

But then I have a compromise to offer.  I'm proposing the underlying
mechanism for date-role anyway: 

http://docs.g-vo.org/vocab-test/date_role/2016-08-17/date_role.html

There, I figured there's no point to keep VO-exclusive terms in the
first place and wanted to totally migrate to DataCite, as Alberto
(essentially) suggests for relationship-type.

However, I don't want to throw away the three terms from
VOResource 1.0 (updated, creation, representative).  There
are (essentially) synonymous terms in DataCite (Updated, Created,
Collected). So, what I'm proposing there is having these terms in the
vocabulary (in order to not break anything right away), but
deprecating them in the sense that new software should accept both;
there's a formal link between the terms (it's
owl:equivalentProperty), so machines can figure out the equivalence
if they want to).

This enables a "soft" transition (which of course means that
non-updated  infrastructure  might "softly" fail for an increasing
part of the resources; but then at least date_role is not used for
anything critical I could think of.  For relationship_type, that
might be different).

For relationship-type, this plan would mean we could introduce
ServiceFor and ServedBy hoping that DataCite will pick them up.

Would that address your concern, Alberto?  Does anyone present have a
particularly strong dislike against this plan?

    -- Markus