<div dir="ltr">Hi Markus,<div><br></div><div>Your arguments sound very reasonable, and I agree with your proposed approach.</div><div>We should avoid breakage until absolutely necessary so your soft transition is a good way to go.</div><div><br></div><div>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.</div><div><br></div><div>-- Alberto</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 5:48 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Registry,<br>
<span class=""><br>
On Mon, Sep 26, 2016 at 11:45:22AM -0400, Accomazzi, Alberto wrote:<br>
> On Mon, Sep 26, 2016 at 5:32 AM, Markus Demleitner <<br>
> <a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a><wbr>> wrote:<br>
</span><div><div class="h5">> > > > a) Go all the way to DataCite style. This breaks some VO<br>
> > > > infrastructure, enough to make me reject that for a 1.1 release<br>
> > > ><br>
> > > > b) Change DataCite terms into the legacy VOResource 1.0 style<br>
> > > > (is-supplement-to, etc). That'd make things somewhat harder for<br>
> > > > VOResource->DataCite translators, but I could live with that. If<br>
> > > > people speak out for this, I'd do it.<br>
> > > ><br>
> > > > I would prefer an homogeneous vocabulary . So option b) gets my<br>
> > preference<br>
> > > > .<br>
> > > I also have a slight preference for option b). And I don't<br>
> > > think having to go to a v.2 (rather than 1.1) is a huge burden,<br>
> > > but people who are directly affected by the change should speak<br>
> > > up!<br>
> > Well, right now, for instance TOPCAT uses the literal string<br>
> > 'served-by'; were we to write 'servedBy' in the future, it would have<br>
> > to use both forms for a while, and current versions of TOPCAT would<br>
> > at some point fail. This piece of code is not yet critical, but I<br>
> > take this as an indication that it's preferable not to touch the<br>
> > relationship terms.<br>
> ><br>
> > So: does anyone actually want to champion (a) -- camel-case the<br>
> > existing terms?<br>
> ><br>
><br>
> I apologize, I now realize that I misspoke when I said my preference was<br>
> b), I intended to "vote" for using the DataCite style if going for a v.2 of<br>
> the standard.<br>
><br>
> Your point about breaking TOPCAT and possibly other applications is a<br>
> concern. Presumably clients to use schema-aware logic to be tolerant in<br>
> what they get from a service, but obviously an older version of TOPCAT<br>
> wouldn't know what to do with a VOResource v.2 record.<br>
<br>
</div></div>I'm not sure I understand the point about schema-awareness -- does<br>
that refer to relationships within the vocabularies? Frankly, I<br>
don't think many clients will use any time soon, and I'm pretty sure<br>
we should be planning for string comparisons between these terms<br>
being prevalent for a long, long time to come -- not the least<br>
because the dominant mode for using them will be comparisons within<br>
ADQL queries (that's what RegTAP is about).<br>
<br>
While, when we actually have use cases, we could add semantic<br>
knowledge to RegTAP and friends using user defined functions, I'd be<br>
reluctant to do that for purely cosmetic reasons.<br>
<br>
So, I suggest we assume for the moment that clients will *not* in<br>
general access any semantic resources when working with the<br>
vocabularies we're discussing here.<br>
<span class=""><br>
> So if we go for a v.2 document then I don't see a reason why we<br>
> should "translate" CamelCase to dash-case(?). So the only reason<br>
> to stick with the current style IMHO is so we can keep the standard<br>
> in the 1.x series.<br>
<br>
</span>-- which is IMHO a strong reason. If I am to break stuff -- and that's<br>
what changing the major version number is about -- I think I'd like a<br>
strong agenda of the type "here's what we really cannot do without<br>
breaking something." Uniform syntax of vocabulary terms in itself is,<br>
I think, not strong enough for me.<br>
<br>
Conformance to an external standard might be; but since it's not<br>
really hard to translate between the two term styles (SomeWords vs.<br>
some-words) automatically, I'd argue that with plan (b) we'd be<br>
following the external standard for almost all intents and purposes.<br>
<br>
But then I have a compromise to offer. I'm proposing the underlying<br>
mechanism for date-role anyway:<br>
<br>
<a href="http://docs.g-vo.org/vocab-test/date_role/2016-08-17/date_role.html" rel="noreferrer" target="_blank">http://docs.g-vo.org/vocab-<wbr>test/date_role/2016-08-17/<wbr>date_role.html</a><br>
<br>
There, I figured there's no point to keep VO-exclusive terms in the<br>
first place and wanted to totally migrate to DataCite, as Alberto<br>
(essentially) suggests for relationship-type.<br>
<br>
However, I don't want to throw away the three terms from<br>
VOResource 1.0 (updated, creation, representative). There<br>
are (essentially) synonymous terms in DataCite (Updated, Created,<br>
Collected). So, what I'm proposing there is having these terms in the<br>
vocabulary (in order to not break anything right away), but<br>
deprecating them in the sense that new software should accept both;<br>
there's a formal link between the terms (it's<br>
owl:equivalentProperty), so machines can figure out the equivalence<br>
if they want to).<br>
<br>
This enables a "soft" transition (which of course means that<br>
non-updated infrastructure might "softly" fail for an increasing<br>
part of the resources; but then at least date_role is not used for<br>
anything critical I could think of. For relationship_type, that<br>
might be different).<br>
<br>
For relationship-type, this plan would mean we could introduce<br>
ServiceFor and ServedBy hoping that DataCite will pick them up.<br>
<br>
Would that address your concern, Alberto? Does anyone present have a<br>
particularly strong dislike against this plan?<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Dr. Alberto Accomazzi<br>Principal Investigator</div><div>NASA Astrophysics Data System - <a href="http://ads.harvard.edu" target="_blank">http://ads.harvard.edu</a><br>Harvard-Smithsonian Center for Astrophysics - <a href="http://www.cfa.harvard.edu" target="_blank">http://www.cfa.harvard.edu</a><br>60 Garden St, MS 83, Cambridge, MA 02138, USA</div></div></div>
</div>