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

GENOVA Francoise (OBS) francoise.genova at astro.unistra.fr
Sat Sep 24 10:29:28 CEST 2016


 Hi all,

I also would be interested by a discussion on Vocabularies in the IVOA. So count on me too.

Francoise


Le Vendredi 23 Septembre 2016 22:18 CEST, "Accomazzi, Alberto" <aaccomazzi at cfa.harvard.edu> a écrit: 
 
> 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
 
 
 
 


More information about the registry mailing list