International Virtual Observatory Alliance

Difference: ProvDiscussionMay2018 (3 vs. 4)

Revision 42018-07-16 - MathieuServillat

  META TOPICPARENT 
  name="ObservationProvenanceDataModel"
- META TOPICPARENT
+  name="ObservationProvenanceDataModel"
-<
<
+ <-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->
 + Proposed change of name for ProvDAL (François Bonnarel):
-<
<
+During the TCG meeting, it has been objected that the name ProvDAL was confusing. Just because in DAL WG, everything is .... DAL !!! I (FB° must confess that I think that I was the one who introduced the name Pr ovDAL , by proximity with "SimDAL". Just because SimDAL is strongly bound to a model and has a PARAMETER based interface. But actually this name (SimDAL) is very atypical in the VO and not reallly appropriate.
->
>
+ Proposed change of name for ProvDAL --> ProvSAP (François Bonnarel):
->
>
+During the TCG meeting, it has been objected that the name ProvDAL was confusing. Just because in DAL WG, everything is .... DAL !!! I (FB must confess that I think that I was the one who introduced the name ProvDAL, by proximity with "SimDAL". Just because SimDAL is strongly bound to a model and has a PARAMETER based interface. But actually this name (SimDAL) is very atypical in the VO and not really appropriate.
 On the other side, everything which has a parameter-based interface, is called Simple Access Protocol in the VO (SSAP, SIAP 1 or 2, SLAP, SCS,...) thus marking an opposition with using ADQL based interface which offers much more query complexity. So after thinking to it and eliminating other bad options we made a consensus on ProvSAP for "Provenance simple access protocol"). I hope that everybody in the group is happy with that. ProvSAP and ProvTAP are easily distinguished this way.
->
>
+ Proposed restructuration of the ProvDM draft: 

 
 section on the core model (without Descriptions, Parameters, ActivityFlow), so fully W3C compliant,
  section for the Descriptions, that are only linked through the Activity-ActivityDescription relation (this would go well with the serialization as a Bundle in the W3C context, that influences the Activity instance)
  section for Parameter (connection of Configuration with Provenance), for which the main use case would be the compatibility with web services in the VO framework, i.e. a Parameter class directly linked to the Activity Class, seen as a simplified Entity that influences the Activity instance. If it is Used, it should then be seen as a general Entity.
  the relation Entity-EntityDescription relation will not be part of the first standard, paragraph in the Appendices (it could be a way to connect Data Structuration with Provenance)
  section on ActivityFlow (connection of Workflows with Provenance), but moved to the Appendices and out of the standard for now (still not well understood)

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