# Contents of /trunk/projects/dm/provenance/description/provaccess_ML2015May2.tex

Revision 4000 - (show annotations)
Tue May 2 21:18:12 2017 UTC (4 years, 4 months ago) by mir.louys
File MIME type: application/x-tex
File size: 5877 byte(s)

 1 \subsection{Provenance Data Model serialization} 2 There are three possible families of ProvenanceDM metadata serializations, examples for these can be found in the implementation section (\ref{sec:usecases-implementations}) and the links therein. 3 \begin{itemize} 4 \item W3C serializations: PROV\-N, PROV\-JSON, PROV\-XML. These are serializations of the W3C provenance data model. They allow the possibility to add additional IVOA or ad hoc attributes to the basic ones in each class. This way the IVOA models can produce W3C compliant serializations. 5 \item Mapping of ProvenanceDM classes onto tables with appropriate relationships. This can allow management by a TAP service (the model mapping is then described with the TAP schema). The serialization will result in a single table according to the query. 6 7 %\TODO{TAP SCHEMA of the ProvenanceDM datamodel: Maybe Mathieu can provide us with a copy of the TAP schema he designed ?} 8 9 \item Direct VOTABLE mapping by using some ad hoc mapping based on transcription of PROV-N format: this is called PROV-VOTABLE. Moreover in the future we could also define a VO-DML \citep{std:VODML} version of the mapping. 10 The following is an example of provenance metadata in this PROV-VOTABLE format. Objects become tables, their classes are rendered by a utype. Attributes and relationships become FIELDS or PARAMS. The model attribute names also become VOTABLE utypes. 11 \begin{verbatim} 12 13 14 19 20 21 22 23 25 27 29 31 33 34 35
cta:telescope_stage_5202015-07-30T09:45:002015-07-30T10:00:00Telescope_stage1.0
36 37 38 39 40 41 42 43 45 47 49 51 53 54 55
cta:Stage1Config_520file
cta:run1000_EVT1EVT1 filefile1000MST21
cta:run13000_EVT0EVT0 filefile13000MST21
56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
cta:telescope_stage_520cta:run13000_EVT0
cta:telescope_stage_520cta:Stage1Config_5250
71 72 73 74 75 76 77 78 79 80 81 82 83
cta:run1000_EVT1cta:telescope_stage_520
84 85 86 87 88 89 90 \end{verbatim} 91 92 93 \end{itemize} 94 95 96 \subsection{Access protocols} 97 We envision two possible access protocols: 98 \begin{itemize} 99 \item ProvDAL: retrieve provenance information based on given id of a data entity or activity 100 101 ProvDAL is a service the interface of which is organized around one main PARAMETER, the ID'' of the entity (obs\_publisher\_did of an ObSDataSet for example). The response is given in one of the following formats: PROV-N, PROV-JSON, PROV-XML, PROV-VOTABLE. Additional parameters can complete ID to refine the query. FORMAT allows to choose the output format. STEP allows to discriminate between STEP=LAST which gives the last step in the provenance chain and STEP=ALL which gives the whole chain. 102 Multiple ID PARAMETER is allowed in order to retrieve several data set provenance details at the same time. 103 \item ProvTAP: allows detailed queries for provenance information, discovery of datasets based on 104 e.g. code version. 105 106 ProvTAP is a TAP service implementing the ProvenanceDM data model. The data model mapping is included in the TAP schema (see above). The result of any query is a single table joining information coming from one or several provenance'' tables available in the database. 107 108 A special case is considered where ProvenanceDM and ObsCore are both implemented in the same TAP service and queried together. The TAP response is then providing an Obscore table with a ProvenanceDM extension. We can imagine that in the future this could be hard-coded and registered as an ObsTapProv service. 109 110 111 \item Do we need combined query possibilities, i.e. ask for ObsCore-fields and Provenance fields 112 in one query? Or rather use a 2-step-process, decoupling them from each other? 113 \end{itemize} 114 115 116 %\TODO{Also look at PROV-AQ from the W3C.}