|
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" |
|