New ProvenanceDM working draft released, part II

[Kristin Riebe]

Hi Markus, DM,

> 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?

Well, in the long run it would be better to have common classes wherever 
possible (and preferably classes compliant with the world outside of the 
VO, i.e. in this case W3C compatible classes). But I'd guess that 
DatasetDM is already so advanced that there will be some reluctance to 
restructure it (which I can perfectly understand).
I guess it should be discussed at the InterOp.

> 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.

That would be easier to do, I think (hope). Experiment (~ Activity) and 
Protocol (~ ActivityDescription) here are derived from the abstract 
"Resource" class - if we don't want to introduce multi-inheritance (and 
I'm pretty sure we don't want that), then we probably need to add the 
Resource class to ProvenanceDM. And we would need to disentangle the 
input/output data relationships ...

> I propose that if we asked our users, they'd rather not have this
> situation, and I submit that if we could start the VO with TAP
> available already, we'd not have SSAP, or perhaps SSAP only as a
> standardised, thin layer on top of ObsTAP with a guarantee that all
> data you get through SSAP is available through ObsTAP, too, and vice
> versa.
> 
> With provenance, we still have the chance to avoid this
> user-unfriendly situation.

Hmm, we'll think about it. One thing I am sure about: I'm going to keep 
my implementation of ProvDAL, because it's useful for me, even if we 
decide at some point to remove it from the standard.

> If ADQL really proves severely inadequate, perhaps this is a use case
> for introducing a new standard language into TAP -- isn't there,
> perhaps, practice outside the VO?  There are tree databases and
> related languages out there, and this also feels a bit as it SparQL
> might help a lot?

That sounds interesting, and Omar recently mentioned something similar 
to me. That's probably worth to be investigated further.

>>> * giving a data model identifier for TAPRegExt indicates there can only
>>>     be one provenance store per TAP service -- is that really what you
>>>     want?  My recommendation for the future is to use URIs in utype
>>>     attributes of schema or table elements.
> 
> Well, it's one of these registry things.  I suppose I should write a
> brief note on this, because it's largely I who's messed this up.
> [...]
> Hence, we're proposing for EPNTAP (there's no WD yet, but
> already quite a few services doing this) to put the ivoid of the
> model into the table's utype; in the above RR, you can see this in
> the mpc.epn_core table:
> 
>    <table>
>      <name>mpc.epn_core</name>
>      <title> EPN-TAP table for MPC Asteroid Orbital Data</title>
>      <description> [...] </description>
>      <utype>ivo.//vopdc.obspm/std/epncore#schema-2.0</utype>
>      [...]
> 
> It is this pattern that I propose to use for DM declaration in the
> future (it also yields nice RegTAP queries).

Thanks for the explanation!
Okay, so we just need to add standard ivo identifiers to each table's 
utype? That can be done.

Cheers,
Kristin

-- 
-------------------------------------------------------
Dr. Kristin Riebe
Press and Public Outreach

Email: kriebe at aip.de, webmaster at aip.de
Phone: +49 331 7499-377
Room:  Bib/3
-------------------------------------------------------
Leibniz-Institut für Astrophysik Potsdam (AIP)
An der Sternwarte 16, D-14482 Potsdam
Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker
Stiftung bürgerlichen Rechts
Stiftungsverzeichnis Brandenburg: 26 742-00/7026
-------------------------------------------------------