VOResource 1.1: relationship type vocabulary/ a common question to various WGs

[Accomazzi, Alberto]

Hi Mireille and Markus,

On Thu, Sep 22, 2016 at 4:58 PM, Mireille Louys <mireille.louys at unistra.fr>
wrote:

> But before that , I want to emphasise that some terms borrowed from the
> Datacite vocabulary definitions are also interesting for representing roles
> in the Provenance DM currently developped .
>
Indeed!

> I think this list of terms and the topic of vocabularies could benefit
> from a splinter meeting or a slot in the Semantic session in Trieste, next
> October.
>
> That would probably mean to allocate a different time slot to the
> Semantics session with at least one Registry session and at least one DM in
> order for interested people to join.
>
> What is your feeling about that?
>
Good idea, count me in.


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

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

These terms might be useful to explicit the roles of various instances in
> the Entity/Activity/Agent pattern
> in the Provenance Model.
> *isDerivedFrom* is a typical link name between a dataset ( entity) and
> its progenitor for instance.
>
> (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.

-- Alberto



>
> Opinions?
>
>         -- Markus
>
>
> [1] Erratum: the link to the content/type vocabulary should of course
> have been http://docs.g-vo.org/vocab-test/content_type in that mail.
>
>
> --
> --
> Mireille Louys
> CDS  							Laboratoire Icube
> Observatoire de Strasbourg		Telecom Physique Strasbourg
> 11 rue de l'Université 			300, Bd Sebastien Brandt CS 10413 		
> F- 67000-STRASBOURG				F- 67412 ILLKIRCH Cedex
> tel: +33 3 68 85 24 34
>
>


-- 
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/semantics/attachments/20160923/55f4b3c6/attachment.html>