[ImageDM]: Provenance

[Arnold Rots]

There are a few more cases than Mireille identified.
I laid that out in a draft note on provenance metadata for individual data
objects:
http://hea-www.cfa.harvard.edu/~arots/VAO/Provenance/ProvenanceMetadata.pdf
http://hea-www.cfa.harvard.edu/~arots/VAO/Provenance/ProvenanceMetadataSummary.pdf

At the very least Provenance metadata need to contain two things:
One or two Relationship value:
  Primary (for services and data objects)
  Mirror of (for services)
  Service for (for services)
  Derived from (for data objects)
  Copy of (for data objects)
  Served by (for data objects)
And one or more RelationshipIDs (URIs, persistent identifiers) associated
with the Relationship.

  - 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
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------



On Fri, Nov 15, 2013 at 9:05 AM, Louys Mireille
<mireille.louys at unistra.fr>wrote:

>
>
>
>
>
>
>
>
>
>
> Hello Mark, all
> in the last discusion I attended about Provenance , I think in
> Heidelberg, I remember we identified two kinds of Provenance:
> 1- instrumental configuration and observing conditions
> 2- processing applied , identifying the progenitors datasets and the
> actions executed on them.
>
> Obscore has only a few items for the instrumental provenance. This can
> be developped further.
> On the contrary the "computational " Provenance is not yet defined but a
> simple sketch is needed to clarify the relationship  between Image and
> ObsData in the current version of ImageDM.
>
> I think this is a secundary specification for this model ( Image) and
> this should not prevent to do the required prototyping right now for the
> main classes already defined.
> More work is needed to express Image <--> ObsData and the
> progenitor-like relationship.
> GAVO is also involved in the definition of the Provenance package and
> the two aspects I mention above.
>
> about the current version for ImageDM:
> May be we could define a "InstrumentalProvenance" class as a hub to
> enter the Provenance Package, as we do for Characterisation DM.
> Or if one prefers , a Provenance Class with two subclasses for
> InstrumentalProvenance and ProcessingProvenance , but this adds one
> level of nesting .
>
> my2c,
> Mireille
> Le 14/11/2013 18:08, CresitelloDittmar, Mark a écrit :
> >
> > There is a bit of confusion about "Provenance", which we should make a
> > statement about.
> >
> > diagram:
> > http://www.ivoa.net/pipermail/dm/attachments/20131113/c9ef7581/attachment-0001.png
> >
> >
> > The ObsCore model does not have a "Provenance" container class.  The
> > associations into the Provenance package are directly to the ObsConfig
> > and Proposal classes.
> >
> > However, the utypes reflect a Provenance node, implying that there
> > should be a container class in the model.
> >
> > Doug's most recent diagram shows a "Provenance" class, which contains
> > the associations to ObsConfig and Proposal.
> >
> > I'd like to make sure this is modeled the way we want it, and then
> > fold that into the migration plan if needed.
> >
> > The options I see:
> >   a) state that there is a mistake in ObsCore, there should be a
> > Provenance class and single association to that.
> >        * my diagram would then add Provenance to the Provenance
> > Package (colored to indicate not in ObsCore doc), with an association
> > from ObservationDataset.
> >        NOTE: This would mean a change to the class hierarchy in
> > ObsCore, so would be a compatibility issue.
> >
> >   b) state that there is no container class "Provenance"
> >        * my diagram could move the associations to ObsConfig and
> > Proposal to "_ObsCore"
> >        * ImageDM would remove that class and inherit the associations
> >
> >
> > Opinions?
> >
> > Mark
> >
>
>
> --
> Mireille Louys	, Maître de conférences
> Centre de Données astrophysiques de  	Icube & Télécom Physique Strasbourg				Pôle API
> Observatoire de Strasbourg 		300, boulevard Sébastien Brant
> 11, Rue de l'Université			CS 10413
> 67000 Strasbourg 			F - 67412 ILLKIRCH Cedexhttp://astro.unistra.fr			http://www.telecom-physique.fr
> tel : 03 68 85 24 34
>
>
>
> --
> Mireille Louys	, Maître de conférences
> Centre de Données astrophysiques de  	Icube & Télécom Physique Strasbourg				Pôle API
> Observatoire de Strasbourg 		300, boulevard Sébastien Brant
> 11, Rue de l'Université			CS 10413
> 67000 Strasbourg 			F - 67412 ILLKIRCH Cedexhttp://astro.unistra.fr			http://www.telecom-physique.fr
> tel : 03 68 85 24 34
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131115/a1e9b7a6/attachment-0001.html>