International Virtual Observatory Alliance

Difference: ProvDayApr2018 (1 vs. 2)

Revision 22018-04-19 - MireilleLouys

  META TOPICPARENT 
  name="ObservationProvenanceDataModel"  

 Provenance Hack-a-thon Session @ in Asterics Tech Forum, 2018/04/17 Summary
- META TOPICPARENT
+  name="ObservationProvenanceDataModel"
-<
<
+ Participants : Mireille Louys, Michele sanguillon, Ole Streicher , Markus Nullmeier, Markus Demleitner, François Bonnarel
->
>
+Participants : Mireille Louys, Michele sanguillon, Ole Streicher , Markus Nullmeier, Markus Demleitner, François Bonnarel
-<
<
+* Markus D. *: how can we realize the simple thing : time series ---> progenitor
->
>
+Markus D.: how can we realize the simple thing : time series ---> progenitor
 Answer:
-<
<
+ Need some description of an Activity : Extraction of a mag from an image etc ..
->
>
+ Need some description of an Activity : Extraction of a mag from an image etc ..
  Follow the Prov relations : wasDerivedFrom or wasGeneratedby + Activity ID+ Used
-<
<
 Carlos's use-case: Provenance from points in a SED or light curve

Linking points in a data set to other data products : extracted image, extracted spectrum, etc. Is it simple to solve?
 

 without the prov DM:
-<
<
+datalink + progenitor link if it exists
  datalink + preview if we want to illustrate only the point via an image
->
>
+datalink + progenitor link if it exists datalink + preview if we want to illustrate only the point via an image
  with provenance info :
-<
<
+   select the wasDerived relation in Prov : it will provide you with a progenitor if present.
->
>
+select the wasDerived relation in Prov : it will provide you with a progenitor if present.
-<
<
+François : linking the prov info from Obscore :
->
>
+François : linking the prov info from Obscore :
 this can be designed with a "prov" column which contains a link to a Prov document in one PROV format (PROV-N, or PROV-JSON)

IVOA PROV Data model design :

A suggestion to handle ActivityDescription by Ole

The PROV-N document is at https://provenance.ecs.soton.ac.uk/store/documents/118181/
-<
<
+The attached Figure contains:
->
>
+The attached Figure contains:
 * Top graph: representation of an activity executed on real data
 * Below graph : Define a template for a an ActivityDescription here "musesci_post" with known roles, with context dependent names, for instance here in the muse:namespace
 a Bundle class (W3C compatible) for expressing ActivityDescription
 - solves the pb of roles
 A realisation of an Activity:
 * uses the activity template
 * uses entities with used roles and generated roles defined in the bundle for description
 Musesci_postT1A : Activity Instance
 has relation "Used" with role "voprov:description" with instance Musesci_post:Bundle
 All other "used" relation should instantiate a role defined in the related Bundle with domain specific namespace, here "muse:"
 Bundle is a W3C class derived from an Entity.
 This should be also possible in a VOTable serialisation
 ** Comment François * : 

 check that this can be coded into the VOTABLE serialsition as well. 

 * Suggestion Michèle * : 

 apply this template solution to a Pollux activity example, using 2 chained activity templates. 

 * Comment Mireille**:
 + by this construction we can gather in just one construct the description part of an Activity , together with the roles ( formally defined as attributes of UsedDescription)
 + the roles at execution can be validated agains the activity template .


<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->
-<
<
->
>
->
>
+ META FILEATTACHMENT 
  attachment="prov-templates.png" attr="" comment="Ole's Activity template together with an instance of an Activity of this type" date="1524174398" name="prov-templates.png" path="prov-templates.png" size="117864" user="MireilleLouys" version="1"
- META FILEATTACHMENT
+  attachment="prov-templates.png" attr="" comment="Ole's Activity template together with an instance of an Activity of this type" date="1524174398" name="prov-templates.png" path="prov-templates.png" size="117864" user="MireilleLouys" version="1"

Revision 12018-04-19 - MireilleLouys

META TOPICPARENT	name="ObservationProvenanceDataModel"

Provenance Hack-a-thon Session @ in Asterics Tech Forum, 2018/04/17 Summary

Participants : Mireille Louys, Michele sanguillon, Ole Streicher , Markus Nullmeier, Markus Demleitner, François Bonnarel

* Markus D. *: how can we realize the simple thing : time series ---> progenitor

Answer:

Need some description of an Activity : Extraction of a mag from an image etc ..
Follow the Prov relations : wasDerivedFrom or wasGeneratedby + Activity ID+ Used

Carlos's use-case: Provenance from points in a SED or light curve

Linking points in a data set to other data products : extracted image, extracted spectrum, etc. Is it simple to solve?

without the prov DM:

datalink + progenitor link if it exists

datalink + preview if we want to illustrate only the point via an image

with provenance info :

select the wasDerived relation in Prov : it will provide you with a progenitor if present.

François : linking the prov info from Obscore :

this can be designed with a "prov" column which contains a link to a Prov document in one PROV format (PROV-N, or PROV-JSON)

IVOA PROV Data model design :

A suggestion to handle ActivityDescription by Ole

The PROV-N document is at https://provenance.ecs.soton.ac.uk/store/documents/118181/

The attached Figure contains:

* Top graph: representation of an activity executed on real data

* Below graph : Define a template for a an ActivityDescription here "musesci_post" with known roles, with context dependent names, for instance here in the muse:namespace

a Bundle class (W3C compatible) for expressing ActivityDescription

- solves the pb of roles

A realisation of an Activity:

* uses the activity template

* uses entities with used roles and generated roles defined in the bundle for description

Musesci_postT1A : Activity Instance

has relation "Used" with role "voprov:description" with instance Musesci_post:Bundle

All other "used" relation should instantiate a role defined in the related Bundle with domain specific namespace, here "muse:"

Bundle is a W3C class derived from an Entity.

This should be also possible in a VOTable serialisation

** Comment François * :

check that this can be coded into the VOTABLE serialsition as well.

* Suggestion Michèle * :

apply this template solution to a Pollux activity example, using 2 chained activity templates.

* Comment Mireille**:

+ by this construction we can gather in just one construct the description part of an Activity , together with the roles ( formally defined as attributes of UsedDescription)

+ the roles at execution can be validated agains the activity template .

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

View topic | History: r2 < r1 | More topic actions...