<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Omar, all<br>
</p>
<br>
<div class="moz-cite-prefix">Le 12/10/2017 à 23:34, Laurino, Omar a
écrit :<br>
</div>
<blockquote
cite="mid:CAFwvi4tjGssuJiaFyuCRPsOBTqEV7EMppn19bi=X7Vxx1M-pUQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">Francois,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<blockquote class="gmail_quote"><span class="gmail-"><br>
<blockquote class="gmail_quote">
Sect. 4.3, PROV-VOTable -- I'm *really* unhappy that a
VO-DML-defined<br>
data model defines a "custom" serialisation while the
authors of the<br>
"mapping" standard (that's supposed to define how such
DMs are to be<br>
represented in VOTable in general) work on something
that looks entirely<br>
different. Everyone will eventually regret that. So,
please, *please*<br>
don't have sect. 4.3; instead, help out the VO-DML
mapping folks and<br>
perhaps fill in any parameters left open in there in a
version 1.1 of<br>
ProvDM.<br>
</blockquote>
</span>
PROV-VOTable is nothing else than the transcription in
VOTable of the tables and relationships of the ProvTAP
schema.<br>
<br>
[...]<br>
<br>
PROV-VOTable format can allow input/output operations of a
whole project provenance metadata in a database system.<br>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAFwvi4tjGssuJiaFyuCRPsOBTqEV7EMppn19bi=X7Vxx1M-pUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</div>
</blockquote>
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. <br>
<blockquote
cite="mid:CAFwvi4tjGssuJiaFyuCRPsOBTqEV7EMppn19bi=X7Vxx1M-pUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
We would be interested to see that. Seems to be a bit of hard work
however.<br>
<blockquote
cite="mid:CAFwvi4tjGssuJiaFyuCRPsOBTqEV7EMppn19bi=X7Vxx1M-pUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"><br>
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 ?)<br>
<br>
</blockquote>
<div><br>
</div>
<div>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.:</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
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 ?<br>
<br>
Cheers<br>
François<br>
<blockquote
cite="mid:CAFwvi4tjGssuJiaFyuCRPsOBTqEV7EMppn19bi=X7Vxx1M-pUQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote">PROV-VOTable is nothing else
than the transcription in VOTable of the tables and
relationships of the <b>vodml-xml model</b>.<br>
[...]<br>
PROV-VOTable format can allow input/output operations of a
whole project provenance metadata in a database system.</blockquote>
<div><br>
</div>
</div>
Note my own edit in bold face.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">It's the same goal as your
PROV-VOTable, really, just standardized for all data models
rather than ad-hoc for a single model.<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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!</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Best,</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Omar.<br>
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">Omar Laurino<br>
Smithsonian Astrophysical Observatory<br>
Harvard-Smithsonian Center for Astrophysics
<div>100 Acorn Park Dr. R-377 MS-81</div>
<div>02140 Cambridge, MA<br>
<span><a moz-do-not-send="true" value="+16174957227">(617)
495-7227</a></span></div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>