Hi Ray,
Yes, thanks for sending the link, this document is pretty
comprehensive, although it does not focus much on database
side of things. I'd recommend for these interested in
provenance to at least skim it. It is pretty long though,
even skimming can take a good chunk of an hour.
Here are some random notes I made while looking at this doc:
- it is very generic. although I could see in several places
they had medical software in mind when designing it. They put
a lot of emphasis on security. As you mentioned, we should
not "just use it". Also, I am not sure if they have a real,
working implementation. If they do, I missed that.
- they have subscriptions: a "managing actor" can subscribe
and receive notifications when provenance objects of specified
type(s) are recorded and/or queried (do we need that?)
- they recognize 3 distinct types of the provenance API:
recording, querying and managing. I think that is a good idea
- they have explicit interface for managing provenance
(e.g overwriting, force deletion...). I think we may need that.
- provenance recording API allows acknowledgments:
"provenance store" can send to provenance "sender" information
that the sent provenance was received and recorded. I think
we need that
- main provenance querying API is: "what is the state of ... at time T".
We have not captured that in uml (yet).
- scalability/locking issues solved by using simultaneously
"multiple stores". They allow links between the "stores".
Our model is similar.
- we don't have in uml model unique ids for provenance objects,
we will probably catch it when we will be mapping these classes
to the SQL.
It is really a good read. I wish I had few uninterrupted hours
to read it.
Jacek
Ray Plante wrote:
Jacek,
A colleague of mine from the NVO project shared this interesting document
on provenance (below). I've only just skimmed it, thus far, but it seems
that the author's primary use case is to be able to store this information
so that it can be queried. I haven't yet seen any explicit reference to
our use case of using provenance data for recreation of data, but I can
imagine that it is "in scope" of their goals if it is not there primary
concern.
Anyway, while I don't want to suggest that "we just use this" (as I
wouldn't know what that would mean), you might find it helpful in
informing how to structure such information in a database.
cheers,
Ray
---------- Forwarded message ----------
Date: Thu, 2 Mar 2006 11:12:29 -0500 (EST)
From: Arnold Rots <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [nvo-techwg] EU Provenance
Here is the documentation of the EU Provenance project:
http://eprints.ecs.soton.ac.uk/12023/01/provenanceArchitecture7.pdf
- Arnold
--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138 [EMAIL PROTECTED]
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
