New ProvenanceDM working draft released, part II

[François Bonnarel]

Dear all,

I want to tackle again one point, which I didn't comment so far.


Le 13/10/2017 à 10:07, Markus Demleitner a écrit :
> Hi DM,
>
> On Thu, Oct 12, 2017 at 11:33:54PM +0200, Kristin Riebe wrote:
>>> Table 17, the mapping between ProvenanceDM and DatasetDM labels.
>>> Frankly, this makes me weep.  Is it *really* not possible to use a
>>> common nomenclature, or rather common types, even between IVOA DMs?  I
>>> have a hard time imagining how I'd implement this, in particular with a
>>> view to "This list is not complete".  And no, "the serialised versions
>>> can be adjusted to the corresponding notation" is not reassuring at all.
>>> How on earth is a piece of software supposed to know what "corresponds"
>>> to a given request?  My impression: For interoperability with the wider
>>> world (W3C), DatasetDM should budge and just use ProvDM classes
>>> whereever possible.
>> In DatasetDM things are structured differently than in ProvenanceDM. For
>> example, we tried to find a good way to integrate Entity/EntityDescription
> Well, DatasetDM is still in WD stage, so perhaps it could be
> re-structured.  Or, even better, perhaps whereever DatasetDM and
> ProvDM have a common domain, the respective classes could be taken
> out of DatasetDM, and DatasetDM would just import what ProvDM has?
It would be good to have common nomenclature, but I don't think it's so 
easy to change DataSetDM.
An frankly speaking I would prefer that we DON'T change it.

DataSet is base on other previous efforts : it is fully compatible with 
Obscore (although more extended) and
Obscore itself was close to SSA. SSA boorowed curation concept to 
Ressource metadata. The distinction between
curation and DataId in DataSetDM is solid and is allready present in our 
ObstAP services.

To achieve the goal of common nomenclature maybe we can rename our IVOA 
provenance attributes to make them consistent with DataSetDM
>
>> with the Dataset-class, but since attributes from Entity and its Description
>> as well as curation details (and thus links to Agents) are combined in
>> Dataset, we couldn't.
>> If we want to "marry" them (and also other
>> similar-yet-not-the-same-classes), this for sure would mean major changes in
>> both models ...
> I'm not so sure about "both".  Since ProvDM largely builds on top of
> an established, external standard, I'd always prefer its solutions
> over custom, VO-only ones in DatasetDM.
BUt some VO-only DatasetDM stuf is 15 years old now and present at 
several places.
>
>>> Table 19 -- oh bother.  Any chance for a SimDM 2.0 that avoids the
>>> duplication of classes?  As far as I can see, there's not terribly much
>>> SimDM 1.0 content out there yet, so perhaps a version 2.0 wouldn't break
>>> too much at this point, would it?
>> There are reasons to have this duplication of classes - e.g if there are
>> many (thousands) experiments run that have the same protocol, but with
> Oh, no, I wasn't talking about the *Description classes -- I still
> find them fishy, but if you've firmly established you can't live
> without them, I'm willing to trust that judgement.
>
> What makes me cringe is that, again, two IVOA DMs model pretty much
> the same domain and use different classes for them.  What I'd like to
> see is that SimDM imports ProvDM's modeling for their modeling of
> Provenance-related information.  That would be beneficial all around.
> On top of that, that'd be a useful test for ProvDM's scope.
I don't know a lot about Theory IG plans, but I'm not sure they are 
going to make a new version of SimDM.
I'm not aware of any SimDM2.0 plan

SimDM is now partially and recently  implemented in the new SimDAL 
protocol. They are a couple of services yet. This makes backward 
compatibilty of the model a practical question...

So in conclusion let's try a clean way to borrow attributes from other 
models into our IVOA ProvDM.

Cheers
François
>
>> slightly different parameters. One could argue that this can be just an
>> optimisation in the implementation, but when serialising the thousands
>> experiments, references to a common protocol instead of replicating all its
>> properties can still become very handy. We use the benefit of that also in
>> our model.