<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, (i) vocabulary term is probably better solution, but (ii) it is easy enough to evolve a model in a compatible way.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 4 Sep 2019 at 04:48, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi DM,<br>
<br>
On Wed, Sep 04, 2019 at 12:43:56PM +0200, Mireille LOUYS wrote:<br>
> Thanks for reading the document and providing your comments.<br>
> <br>
> Concerning the definition of a vocabulary for some attributes of the<br>
> Provenance model, like Agent Role literals,<br>
> <br>
> I think the DM specification should not rely on the current elaboration of<br>
> the vocabulary definition proposed by the Semantics WG.<br>
<br>
The problem is that it's hard to put in anything normative later,<br>
because if there's anything like a "must" (as in VO-DML<br>
semanticConcept), you'd be invalidating existing instances -- and so<br>
you'd need a new major version of ProvDM.<br>
<br>
You could probably move enums to vocabularies (this would be relaxing<br>
constraints, which might still break clients, though). However, the<br>
enums would have to be defined, and I don't think anyone would want<br>
to do that.<br>
<br>
Finally, you could put in "should"s. But until then you'll have<br>
natural language in the fields, and that will make it very hard to<br>
interoperably do much interesting with them.<br>
<br>
> For now, these literals should be part of the PROV-DM specification , and<br>
> when we have feedback from implementations ,<br>
> we will be able to understand the needs for evolution for these lists of<br>
> terms better, and propose an IVOA provenance vocabulary.<br>
<br>
Well, this is exactly what we have vocabularies for: Start with a<br>
minimal set, add terms as necessary.<br>
<br>
> By adding too many constraints on this specification , we will delay it<br>
> again, and it is not what we wish for the IVOA.<br>
<br>
Given that there are no WG reviews in yet, I'd say we easily have a<br>
few weeks to work out whether there's really much to do; my take is:<br>
it's two really small vocabularies, and it's adopting datalink/core<br>
where it's pertinent. To me, that sounds eminently feasible. And<br>
will make ProvDM a better and more useful standard.<br>
<br>
-- Markus<br>
</blockquote></div>