Provenance Telecon September 2017

Sep 05, 2017, 10-12am

Participants:

• Mireille,
• Francois,
• Mathieu,
• Kristin,
• Ole,
• Anastasia

Time table

• Has to be checked
• Final draft by Friday, 15th of September
• Next telecon - September the 12th, 10am

• Last two weeks of September - discussion inside the DM group
• Mathieu:
  • writes 4.1.1, 4.1.2, 4.1.3, see below
  • entity description
  • how to use the model section - parts, to be expanded
• Kristin:
  
  • makes the examples shiny (section 4.1)
  • Prov DAL document goes into PROV draft
• Francois and Mireille:
  
  • PROV-VOTABLE, PROV-TAP (see above)
  • HIPS exampled - addition of ProvTAP
• Ole:
  • use cases into section 6.
• Everyone - Please add a paragraph on implementations in the implementation note.

• Page 5:
  • ID: can be of an entity, activity or an agent
  • Default value for DEPTH is one
  • Question: Must ALL keyword be implemented in a service? For instance, could a service set ALL as a redirect to 1?
    • General opinion here is that implementing ALL is required for the server.
  • Members of a Collection is only tracked if MEMBERS keyword is set to TRUE.
  • In the same way, singuar steps of an ActivityFlow is only tracked if STEPS keyword is set to TRUE.
  • The hierarchical relationships between activities and ActivityFlow as well as entities and Collections are counted in the DEPTH number of relations.
  • AGENT - better keyword or options -
    • AGENT = EXPLORE, AGENT = ENDPOINT
    • or EXPLORE-AGENT, TRACKAGENT set to TRUE or FALSE
    • leave as it is but open to discussion
  • FORMAT default is set to JSON.
• Page 4:
  • The relationship between members of collection or of the activity flow is of hierarcical nature and not to be treated in the same way as a resposibility relation.
• Page 3:
  • Suggestion: format can be specified via the HTTP accept header which is common practice for HTTP services wget -d --header="Accept: application/json" {provdal-base-url}?ID=rave:dr4
  • will be discussed further
  • W3C has implementation, has to be checked
  • (W3C) clients communicate for example via json and expect this specific format back

• Reference implementations are to be put into the wiki - RFC page -
  
  • django.prov_vo, voprov-python, OPUS UWS Server
  • Implementation notes
• Section 6 - use cases, examples, how to use the model
  • exists in parts, must be expanded
  • usecases
• ProvTAP: is it part of the standard or optional?
  • maybe not mature enough
  • should be part of the standard and
  • ProvTAP needs more explanation, TAP-VOTABLE is not PROV-VOTABLE and has to be mapped
  • how to convert it to VOTABLE
  • Section 6.5 - addition of ProvTAP in the text
• Section 4.1 - new structure - how to structure the VOTABLE and how to map the data model into the VOTABLE
  • 4.1.1 - W3C
  • 4.1.2 - VOTABLE
  • 4.1.3 - description serialization
• Separate document for VOTABLE description?
  • Will be proposed by Francois and Mireille
• Entity description will be expanded
  
  • link to the published entity - does it have to be covered in the draft?
  • EntityDescpription is what you know about the entity before the entity is produced.