New ProvenanceDM working draft released

[François Bonnarel]

Hi Omar, all


Le 12/10/2017 à 23:34, Laurino, Omar a écrit :
> Francois,
>
>
>         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.
>
>     [...]
>
>     PROV-VOTable format can allow input/output operations of a whole
>     project provenance metadata in a database system.
>
>
> By definition, at least from what I saw in the Provenance WD, this is 
> what the Mapping standard is supposed to cover. One difference with 
> what you wrote is that you don't need to define ProvTAP first, which 
> is rather another mapping target.
That's the point. We had the impression that VO-DML mapping into VOTable 
will not help us to define a TAP schema for Provenance. The version 
annouced recently by Laurent is not, as far as I understand, seems to 
confirm that.

>
> If ProvenanceDM has a valid VODML representation, VOTable 
> representation of its instances will be defined by the standard 
> mapping mechanism, without requiring an ad-hoc serialization definition.
If we could find a standard way to go from "vo-dml xml" represntation of 
any IVOA data model to TAP schema that would be better than ad hoc 
serialisation.
>
> To have two different potential serializations doesn't seem 
> appropriate. So my +1 goes to Markus' suggestion. I had an iteration 
> with Kristin as I hoped I could find some time to come up with 
> standard VOTable serializations according to the Mapping WD for 
> Provenance instances, but I've been working a lot on the STC and 
> TimeSeries/Cube models and serializations, and couldn't get to 
> Provenance just yet.
>
We would be interested to see that. Seems to be a bit of hard work however.
>
>
>     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 ?)
>
>
> I would argue that "very complex" in this context really means 
> "standardized", but I don't think a conversation on the subjective 
> perception of complexity is useful, my main point just being that the 
> Mapping document does (almost) exactly what you described above, i.e.:
>
Again "as far as I understand it", VO-DML mapping into VOTABLE provides 
a set of TAGS in an xml schema extension of VOTABLE defined to describe 
instances of a model. At some point it integrates references to elements 
of a classical VOTable where the actual data/metadata values are stored.
I said "complex" because by looking at the examples it took me a while 
to understand what the structure is really doing and I was reluctant to 
strat writing such a structure for Provenance.
Moreover, this doesn't help me to build this classical VOTable itself. I 
don't think the object/relational mapping of a data model is currently 
done in the proposed spec. This is a real missing point.

On another side the response to a query  of a TAP service is a single 
table joigning columns from various tables as described in the schema. 
ProvTAP response will be no exception.

Responses variation is almost infinite. The number and content of 
possible involved columns is very large. So the model VO-DML mapping to 
the VOTable response must be done dynamically, which  probably forbids 
easy usage of public libraries.  While in our approach the "TAP schema" 
representation of the model contents everything to describe the model 
and identify it in the response as long as we consider it is a valid 
relational transcription of the vo-dml xml representation of the model. 
Can we standardize that ?

Cheers
François
>
>     PROV-VOTable is nothing else than the transcription in VOTable of
>     the tables and relationships of the *vodml-xml model*.
>     [...]
>     PROV-VOTable format can allow input/output operations of a whole
>     project provenance metadata in a database system.
>
>
> Note my own edit in bold face.
>
> It's the same goal as your PROV-VOTable, really, just standardized for 
> all data models rather than ad-hoc for a single model.
>
> We are definitely going to discuss suggestions on the simplification 
> of the syntax for the Mapping WD, so if you have any such suggestions 
> please send them our way!
>
> By currently focusing on important data models like STC, Cube, and 
> TimeSeries (and Provenance asap) we can finally see everything coming 
> together. With such implementation experience, actual serializations 
> of actual models to look at and compare we can then go back to discuss 
> about the syntax more pragmatically.
>
> Best,
>
> Omar.
>
> -- 
> Omar Laurino
> Smithsonian Astrophysical Observatory
> Harvard-Smithsonian Center for Astrophysics
> 100 Acorn Park Dr. R-377 MS-81
> 02140 Cambridge, MA
> (617) 495-7227

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20171013/7e79ed29/attachment-0001.html>