Fwd: Re: [ImageDM]: Provenance

[Louys Mireille]

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 Cedex
http://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 Cedex
http://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/aff04814/attachment-0001.html>