New ProvenanceDM working draft released

[François Bonnarel]

Dear Markus,

dear all,

Thank you for the reviewing carefully the draft.

My answer on two of your points, Markus.

> Sect 5 -- I'm not sure if I'm terribly happy to have an access protocol
> folded into this already fairly long document (on the other hand: the
> less standards the better).  But one thing I'm sure about is that you
> don't want two access protocols.  It'll be hard enough to gain uptake
> for one of them.  If you let people choose which one to implement, in
> all likelihood half will use one protocol, and the other half the other,
> thus at least doubling the implementation effort for client authors.  My
> take: There are enough TAP engines available that there is no reason not
> to just use TAP plus a canonical relational DM representation,
> preferably built according to standard, VO-DML rules.

This has been a long discussion among the authors. I'm happy to see that 
you agree with
the existence and definition of "ProvTAP" services. But these will allow 
sophisticated queries by selection constrained any
attribute of any class (or any combination of attributes) in the 
provenance metadata. Examples of such queries
are given in the draft

There is a simpler need which may be sufficient for many of the projects 
: follow the processing flow in whatever direction starting from an
identified "entitity" or "activity". This is what ProvDAL is for.

Our guess : most of the project will implement ProvDAL. This can be done 
by storing provenance details close to more classical dataset metadata 
in you DAL service implementation background.

Some project will require more complete ProvTAP services. It will be 
easy to build a ProvDAL layer on top of this kind of ProvTAP service.


> Sect. 4.3, PROV-VOTable -- I'm *really* unhappy that a VO-DML-defined
> data model defines a "custom" serialisation while the authors of the
> "mapping" standard (that's supposed to define how such DMs are to be
> represented in VOTable in general) work on something that looks entirely
> different.  Everyone will eventually regret that.  So, please, *please*
> don't have sect. 4.3; instead, help out the VO-DML mapping folks and
> perhaps fill in any parameters left open in there in a version 1.1 of
> ProvDM.
PROV-VOTable is nothing else than the transcription in VOTable of the 
tables and relationships of the ProvTAP schema.

We can even remove the name if this is controversy. BY theses VOTable 
wil exist anyway.

PROV-VOTable format can allow input/output operations of a whole project 
provenance metadata in a database system.

The ProvTAP schema is a relational transcription of the provenance 
object datamodel.

It is quite parallel to what you have done with RegTAP by mapping an 
"xml schema" description of the Resource metadata model into a set of 
tables and relationships which we find out in the RegTAP schema.

In ProvTAP the starting point is no more an "xml schema" description but 
an UML, and even more a vo-dml-xml description of the model which we map 
into a relational structure expressed as a TAP schema. The TAP schema 
itself will be presented in Santiago.

I agree it would be nice to have a generic way of transcripting 
vo-dml-xml model descriptions into TAP schemas mapping these models.

As   far as I understand this is not what is performed by the current 
effort on "VO-DML mapping into VOTable" which is more oriented on a 
(very complex) mapping of the model structure on a single table (or an 
unknown structure of tables ?)


Cheers
François
>