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

[Mireille Louys]

Hi Markus, Hi all,

You will find my comments inserted below in the original text.

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 .

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?

Cheers , Mireille.


Le 20/09/2016 à 15:56, Markus Demleitner a écrit :
> Dear Registry,
>
> As explained in the mail
> http://mail.ivoa.net/pipermail/registry/2016-August/005112.html  [1]
> I plan for VOResource to externalise some vocabularies.  The initial
> vocabularies would come with VOResource 1.1, and thus I'd like to
> have them reviewed as if they were part of the schema.
>
> Today, can I bother you for opinions on the successor to
> relationship/type:
>
> http://docs.g-vo.org/vocab-test/relationship_type
>
> Points I feel uncertain about:
>
> (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 .
> (2) concept selection.  Right now, the predicates for
> relationship_type are
>
> mirror-of service-for served-by derived-from related-to
> Cites
> IsSupplementTo IsSupplementedBy
> IsContinuedBy Continues
> IsNewVersionOf IsPreviousVersionOf
> IsPartOf HasPart
> IsSourceOf
>
> I'm pretty sure IsContinuedBy and in particular Continues are
> valuable additions, leading people along the resource development
> (e.g., services going down).  IsSourceOf is nice because we
> traditionally had derived-from, and this would finally provide the
> inverse.
>
> Is*VersionOf would let people chain together various data releases,
> and since different services for different data releases is something
> fairly common in today's VO, I think having this helps in very real
> cases.
>
> IsPartOf and HasPart I'd see as useful when, e.g., SDSS starts
> registering individual tables or so.
>
> Cites is DataCite's closest match for what education wanted in their
> educational registry extension.  Essentially, I'd like to have this
> for the discovery use case "give me tutorials that work with tool X".
>
> The *Supplement* terms are a bit fringy to me.
>
> 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?
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.
>
> Opinions?
>
>          -- Markus
>
>
> [1] Erratum: the link to the content/type vocabulary should of course
> have beenhttp://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160922/eb09d36c/attachment.html>