Minutes of the provenance splinter meeting in ADASS 2017 -10-26 Ole, Catherine, Mathieu, Michèle, François, Markus N., Laurent, Mireille questions adressed on the dm mailing list 1)Freedom in implementation / definition of the model about description classes for Activity, entity, parameter, Used ?? They are introduced in the model, after considering the SIMDM description part. useful to gather together several activities of same type and factorise their common description several use-cases implementation show that : we would like to gather in the same class/table attributes of ActivityDesc together with Activity. Flexibility against interoperability : the same query is not possible across diff. projects : diff. serialisation names 2 classes : Activity.description points to an ActivityDescription Class ActivityDescription.name = "Hipsgen" 1 class: Activity.description.name = "Hipsgen" if description belongs to Activity as an embedded attribute of type : ActivityDescription. SVOM project, Laurent: Description must be mentioned. not sure which solution to adopt but rather 1 class would be preferred. PB: Description class by itself does not belong to W3C and cannot be expressed directly we need an extra way to embed the description in PROv-N, PROV-JSON 2) What is the goal and rationale for Prov-VOTABLE format - as a VO service, distribute data in VOTABLE - serves to describe the database design in VOTable format and export the related data values - plays the role of TAP_SCHEMA.tables and their description in one VOTable format (FB) action François: check the TAP spec for the expression of the TAP Schema and make an attempt to derive the TAP_SCHEMA tables from the current version of Prov-VOtable. Formats for the TAP query response can be VOTable (1 table only), JSON, but in that case table structure not present. Representation of the content of a query response can be a graph in JPG, PNG, PDF as proposed by Southampton Provenance Suite 3) DAL Access to provenance : PROV-DAL : useful when the implementer has a small collection and no TAP service. The implementation is light weight and up to the server application. Simple logic applies on the server application and few constraints are given in the standard. Can be described in the DM doc as it is. PROV-TAP is needed too. Must be mentioned in the DM doc, but explained in detail in a specific DAL document . Action FB and group to write a skeleton for a DAL prov-TAP document. A data provider can support both TAP queries and PROV-DAL queries. 4) Convergence of models DatasetDM and SimDM models with Provenance These DM have been designed for different purposes. Their common attributes do not need to be the same, but the spec can explain the amount of re-use of the concepts from Dataset DM and SimDM in the provenance concept. The appendix should be a better place in order not to stress the point in the normative part of the spec. Make the link between an entity and a dataset more explicit in the UML access link, multiplicity , etc . 5) DOI are used by some providers and supposed to bind some provenance info to the data. Is it part of IVOA PROV DM? ( question from Arnold) PROV DM requires unique identifiers for all main classes. There is a one to one binding from entity to a dataset, but this depends on the provider's policy. Not all data providers will be allowed to mint DOIs, only some national/organisations Agencies . Some entities internal to a project may not be shown outside, so do not need to be published --> DOIs not required 6) Was derived from, was informed by, was influenced by : these relations are part of the W3C model. Do we really need them in IVOA PROV DM? Most of the present people here in the meeting think no. Should not be mandatory to implement. wasDerivedFrom introduces some ambiguity in the length of the path for Prov DAL (skip/hide the activity) --> not fully comparable from one implementation to another.