VOResource 1.1: relationship type vocabulary

[Accomazzi, Alberto]

Hi Markus,

Your arguments sound very reasonable, and I agree with your proposed
approach.
We should avoid breakage until absolutely necessary so your soft transition
is a good way to go.

Regarding the topic of getting involved in DataCite, I thought some of the
people on this mailing list (including you Markus) were already involved in
the discussions related to metadata schema and standards given that we have
spoken about registering DOIs with them.  I don't mind paying closer
attention but I really think having representation from places like the CDS
and ST would be desirable.

-- Alberto


On Tue, Sep 27, 2016 at 5:48 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

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



-- 
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/20160928/fe852674/attachment.html>