Difference: ProvTeleconSeptember2017 ( vs. 1)

Revision 12017-09-05 - OleStreicher

 
META TOPICPARENT name="ObservationProvenanceDataModel"

Provenance Telecon September 2017

Sep 05, 2017, 10-12am

Participants:

  • Mireille,
  • Francois,
  • Mathieu,
  • Kristin,
  • Ole,
  • Anastasia
Documents: provdal.pdf - ProvDAL draft from Kristin

Time table

  • Has to be checked
  • Final draft by Friday, 15th of September
  • Next telecon - September the 12th, 10am
TODO:
  • 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.
ProvDAL (refers to provdal.pdf)

  • 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
Prov draft (refers to rev4224 of ProvenanceDM.pdf)
  • 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.

META FILEATTACHMENT attachment="provdal.pdf" attr="" comment="" date="1504614478" name="provdal.pdf" path="provdal.pdf" size="492406" user="OleStreicher" version="1"
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback