PR#2 for Provenance DM : syncronicity with vocabularies definition in Semantics WG

[Patrick Dowler]

In my experience evolving CAOM, it is possible to change from an enum to a
vocabulary term without invalidating existing instances (stored in
databases, eg). It does require that one use the datalink-style where you
do not need to prefix terms from the core vocabulary with the vocabulary
URI (plus/minus keeping the # like we did in datalink - a small issue).
This has been a common evolution in CAOM. The reason is that as people use
the model they want to add new terms (usually to be more specific) and the
new terms are not C(ommon) enough to go into an enum; instead, we relax
constraints by making the field a vocabulary term.

So, (i) vocabulary term is probably better solution, but (ii) it is easy
enough to evolve a model in a compatible way.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 4 Sep 2019 at 04:48, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi DM,
>
> On Wed, Sep 04, 2019 at 12:43:56PM +0200, Mireille LOUYS wrote:
> > Thanks for reading the document and providing your comments.
> >
> > Concerning the definition of a vocabulary for some attributes of the
> > Provenance model, like Agent Role literals,
> >
> > I think the DM specification should not rely on the current elaboration
> of
> > the vocabulary definition proposed by the Semantics WG.
>
> The problem is that it's hard to put in anything normative later,
> because if there's anything like a "must" (as in VO-DML
> semanticConcept), you'd be invalidating existing instances -- and so
> you'd need a new major version of ProvDM.
>
> You could probably move enums to vocabularies (this would be relaxing
> constraints, which might still break clients, though).  However, the
> enums would have to be defined, and I don't think anyone would want
> to do that.
>
> Finally, you could put in "should"s.  But until then you'll have
> natural language in the fields, and that will make it very hard to
> interoperably do much interesting with them.
>
> > For now, these literals should be part of the PROV-DM specification , and
> > when we have feedback from implementations ,
> > we will be able to understand the needs for evolution for these lists of
> > terms better, and propose an IVOA provenance vocabulary.
>
> Well, this is exactly what we have vocabularies for:  Start with a
> minimal set, add terms as necessary.
>
> > By adding too many constraints on this specification , we will delay it
> > again, and it is not what we wish for the IVOA.
>
> Given that there are no WG reviews in yet, I'd say we easily have a
> few weeks to work out whether there's really much to do; my take is:
> it's two really small vocabularies, and it's adopting datalink/core
> where it's pertinent.  To me, that sounds eminently feasible.  And
> will make ProvDM a better and more useful standard.
>
>         -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190904/6dff85ab/attachment-0001.html>