%In this section we discuss how the Provenance Data Model interacts with
%classes and attributes from other VO data models (especially DatasetDM).
%(e.g. DatasetDM, SpectralDM (share some same classes), SimDM) 
%and how provenance information can be stored.

The Provenance Data Model can be applied without making any links to other 
IVOA data model classes. 
However, other IVOA standards and external models contain concepts that can be mapped with some Provenance DM concepts. This section provides links between those concepts, and gives some elements to extend the Provenance DM.

For example, when the data is not yet published, provenance information
can be stored, but a DatasetDM-description for the data may not yet exist.
However, if there are data models implemented for the datasets, then it is 
very useful to connect the classes and attributes of the other data models with provenance classes and attributes (if applicable), which we are going to discuss in this Section. These links help to avoid 
unnecessary repetitions in the metadata of datasets, and also offer the possibility 
to derive some basic provenance information from existing data model classes automatically, e.g. for creating provenance serializations from DatasetDM or SimDM metadata.



\subsection{Links with the IVOA Dataset/ObsCore models}
\label{sec:dataset-obscore}

\class{Entity} and \class{EntityDescription} in ProvenanceDM 
are tightly linked to the \class{DataSet}-class in DatasetDM/ObsCoreDM \citep{std:DatasetDM, std:OBSCORE}, as well as to 
\class{InputDataset} and \class{OutputDataSet} in the SimulationDM \citep{std:SimDM}.
Tables~\ref{tab:datasetmapping} and \ref{tab:datasetmapping2} map classes and attributes from DatasetDM
to concepts in ProvenanceDM. 
%If the DatasetDM attributes are used in the serialization of an entity, they have the corresponding DatasetDM namespace.


%\begin{figure}[ht]
%\centering
%\includegraphics[width=\textwidth]{../datamodel-diagrams/images/classes-relations-dms}
%\caption{Links between Agent and Party, Entity and Dataset.}
%\label{fig:class-relations-dm}
%\end{figure}
% --> a similar figure is already given in the sections on entity and agent.


\begin{table}[ht]
\small
\tymax  0.5\textwidth
\begin{tabulary}{1.0\textwidth}{LlL}
\toprule
\head{ProvenanceDM attribute} & \head{DatasetDM attribute} & \head{Comment}\\
\midrule
Entity.id                & Curation.PublisherDID  & unique identifier for the dataset assigned by the publisher\\
Entity.id                & DataID.creatorDID      &  alternative id for the dataset given by the creator, could be used as Entity.id if no PublisherDID exists (yet)\\
Entity.name              & DataID.title           & title of the dataset\\
Entity.rights            & Curation.Rights        & access rights to the dataset; one of [...]\\
Entity.creationTime      & DataID.date            & date and time when the dataset was completely created\\
HadMember.collection     & DataID.collection     & link to the collection to which the dataset belongs\\
WasGeneratedBy.activityId & DataID.ObservationID  & identifier to everything describing the observation\\
Agent                    & Curation.Contact       & link to Agent with role contact\\
Agent.id                 & Curation.PublisherID   & link to the publisher, i.e. to an Agent with role=``publisher''\\
Agent.name, \newline wasAttributedTo.role=\newline Creator               & DataID.creator         & name of agent creating the dataset\\
Agent.name, \newline wasAttributedTo.role=\newline Publisher               & Curation.Publisher     & name of the publisher\\
\bottomrule
\end{tabulary}
\caption[Mapping attributes from DatasetDM classes to attributes in ProvenanceDM]{Mapping attributes from DatasetDM classes to (optional) attributes in ProvenanceDM. This list is not complete.}
\label{tab:datasetmapping}
\end{table}


\begin{table}[ht]
\small
\tymax  0.5\textwidth
\begin{tabulary}{1.0\textwidth}{llL}
\toprule
\head{ProvenanceDM class} & \head{DatasetDM attribute} & \head{Comment}\\
%\midrule
%\multicolumn{3}{c}{\bf Attributes specific to dataset entities}\\
\midrule
Entity           & Curation.Date          & release date of the dataset\\
Entity           & Curation.Version       & version of the dataset\\
Entity           & Curation.Reference     & link to publication\\
EntityDescription & DataProductType & the type of a dataproduct from DatasetDM can be used as attribute to EntityDescription\\
EntityDescription & DataProductSubType    & subtype of a \mbox{dataproduct}/entity\\
EntityDescription & ObsDataset.calibLevel & (output) calibration level, integer between 0 and 3\\
\bottomrule
\end{tabulary}
\caption[Mapping attributes from DatasetDM classes to the ProvenanceDM classes]{Mapping attributes from DatasetDM classes to the ProvenanceDM classes to which they could be added. Attributes like \attribute{EntityDescription.calibLevel} are very specific to entities described with DatasetDM and thus are not included in this ProvenanceDM directly. This list is not complete.}
\label{tab:datasetmapping2}
\end{table}


The \class{Agent} class, which is used for defining responsible persons and 
organizations in ProvenanceDM, is very similar to the \class{Party} class in DatasetDM (and in SimDM). Its details are depicted in Figure~\ref{fig:agent-relations}.
The main difference between \class{Agent} and \class{Party} is that \class{Individual} and \class{Person} are subclasses in DatasetDM, whereas we just use the same class \emph{Agent} for both and distinguish between them using the \emph{Agent.type} attribute (which can have the value ``Individual'' or ``Organization''), which is closer to W3C's provenance data model.
% Which is closer to W3C ProvDM!

\begin{figure}[ht]
\centering
\includegraphics[width=\textwidth]{agent-relations.pdf}
\caption[Agent in ProvenanceDM and Party in DatasetDM]{The relations between the \class{Agent} class within ProvenanceDM 
(grey and yellow classes) with classes from the DatasetDM, party package (green).}
\label{fig:agent-relations}
\end{figure}

We imagine that services implementing both data models, \class{Dataset} and \class{ProvenanceDM} may just use \emph{one} class: either \class{Agent} or \class{Party}, enriched with all the necessary (project-specific) attributes. When delivering the data on request, the serialized versions can be adjusted to the corresponding notation.
Note that for Provenance queries using a ProvTAP service or for W3C compatible serializations, the name \class{Agent} for the responsible individuals/organizations is required.




\subsection{Links with the IVOA Simulation Data Model}

In SimDM \citep{std:SimDM}, one also encounters a normalization similar to our separation of descriptions from 
actual data instances and executions of processes: the SimDM class \class{Experiment}
is a type of \class{Activity} and its general, reusable description is called a \class{Protocol},
which can be considered as a type of this model's \class{ActivityDescription}. 
More direct mappings between classes and attributes of both models are given in Table~\ref{tab:simdmmapping}.

\begin{table}[ht]
\small
\tymax  0.5\textwidth
\begin{tabulary}{1.0\textwidth}{LLp{5cm}}
\toprule
\head{ProvenanceDM} & \head{SimDM} & \head{Comment}\\
\midrule
Activity               & Experiment      &  \\
Activity.name          & Experiment.name & human readable name; name attribute in SimDM is inherited from Resource-class\\
Activity.endTime & Experiment.executionTime  & end time of the execution of an experiment/activity \\
Activity.description & Experiment.protocol & reference to the protocol or ActivityDescription class \\
ActivityDescription    & Protocol        & \\
ActivityDescription.name  & Protocol.name   & human readable name\\
ActivityDescription.doculink & Protocol.referenceURL & reference to a webpage describing it\\
% add Protocol.code, Protocol.version?
Parameter              & ParameterSetting     & value of an (input) parameter\\
ParameterDescription   & InputParameter       & description of an (input) parameter\\
Agent           & Party           & responsible person or organization\\
Agent.name      & Party.name      & name of the agent \\
WasAssociatedWith & Contact         & classes for linking to agent/party\\
WasAssociatedWith.role & Contact.role    & role which the agent/party had for a certain experiment (activity); SimDM roles contain: \texttt{owner}, \texttt{creator}, \texttt{publisher}, \texttt{contributor}\\
WasAssociatedWith.agent & Contact.party    & reference to the agent/party \\
Entity        & DataObject     & a dataset, which can be/refer to a collection\\

\bottomrule
\end{tabulary}
\caption[Mapping between classes and attributes from SimDM to classes/attributes in ProvenanceDM]{Mapping between classes and attributes from SimDM to classes/attributes in ProvenanceDM. This list is not complete.}
\label{tab:simdmmapping}
\end{table}

If simulations are already described with SimDM, this table can be used
to map from SimDM properties to ProvenanceDM, e.g. when serving serialized provenance metadata via an additional ProvSAP interface or for storing provenance metadata together with each released simulation dataset (e.g. in a VOTable).

% Remove this, because no further links to other data models are currently planned.
%\subsection{Further links to data models}
%More similarities and links to other data models will be detailed in future
%versions of this working draft.




\subsection{Links with the IVOA UWS pattern}
\label{sec:uws_links}

The IVOA Universal Worker Service Pattern \citep{std:UWS} defines how to manage asynchronous execution of jobs on a service. Within this pattern, a \class{Job} can be seen as an \class{Activity}. A job uses input parameters and generates results.

\paragraph{Job Description Language.}
The UWS pattern states that ``the rules for setting and arranging the parameters for a job are called the Job-Description Language (JDL). The combination of the UWS pattern, a JDL and details of the job state visible to the client defines a service contract''.
It is interesting to map this JDL with the Activity Description classes defined in the Provenance DM (section~\ref{sec:activity_desc}). When using the Activity Description classes as a JDL, a service following the UWS pattern is turned into a ``universal worker service''. This service is in addition \emph{Provenance enabled}, in that the provenance information can be automatically generated from the JDL.
The serialization proposed in section~\ref{sec:description-serialization} completes the definition to make the JDL exchangeable.

\paragraph{Value of UWS parameters.}
The definition of UWS parameters corresponds to the definition of the \class{Parameter} class (see Section~\ref{sec:parameters}. 
The UWS pattern states that ``each parameter value may be expressed either directly as the content of the parameter element, or the value expressed \emph{by reference}, where there returned parameter value is a URL that points to the location where the actual parameter value is stored''.
A parameter value may also be an identifier, a serial number, a file name, that points to an external entity. 
It is generally not clear if the parameter value points to an input or output entity, or if it is just some value. 
This is resolved in the UWS pattern \citep{std:UWS} by adding an attribute \attribute{byReference=true} to a parameter if it is an URL to be resolved.
%To remove this ambiguity, 
%one could describe the used or generated entity in the UsedDescription or WasGeneratedByDescription classes presented in the next section, using the same name as the parameter. 
%This would indicate that an entity is connected to an activity by simply giving its identifier through a parameter.
In the same way, this can be resolved in the Provenance DM by adding to a \class{ParameterDescription} instance a link to a \class{UsedDescription} instance that explains in details the referenced external entity.
In that case, the \class{ParameterDescription} instance should indicate that the parameter is an identifier (e.g. \attribute{ucd="meta.id"} or \attribute{ucd="meta.file"}) or a URL (\attribute{xtype="xs:anyURI"}), and the \attribute{role} of the corresponding \class{UsedDescription} instance must be the \attribute{name} of the \class{ParameterDescription} instance.
%The \class{ParameterDescription} may thus point to a \class{UsedDescription} for the same \attribute{role} that describes the content of the referenced entity.

%The associated \attribute{utype} may point to \attribute{Entity.id}.

% comment from Ole
% I don't understand the chapter above: Since a Parameter is an Entity, it may have a 
% \attribute{value} or a \attribute{location}, depending on whether it is the value itself or
% a reference. Why would you put an URL into the \attribute{value} field then?
% If we split the ParameterDescription into an EntityDescription and a UsedDescription, then
% there is no need to specify \attribute{utype} in case of references at all. And we can use
% ucds & Co. in entity related values that are no parameters.

%Mathieu: I tried to modify the text, following the last model. the value attribute can contain a URL or simply a filename because this exist in practice. We may excahnge just identifiers with an activity, then the activity has to resolve this identifier. This way we explicitely know that there is a used entity. Sometimes this is not known a priori from the list of parameters (even the from the uws parameters).

%ole If it contains a file name or a link, than it is an ConfigFile Entity, not a Parameter, and this file should have a proper EntityDescription.
%ole You usually always feed file names or URLs into a program; almost never the file itself (except if it comes from stdin or such, but this is probably rare in astro).
%ole For example, ESO recipes get a command line parameter "fname.sof", which contains a list of input and calibration files.
%ole This translates into one Entity per file (*not* one Parameter), and not having an (irrelevant) "fname.sof" parameter.
%ole Parameters are by-value; we should take this seriously. If a reference is given, it is not a Parameter, even when it was done on the command line. Otherwise, one may break Provenance dependencies: how do I come from a file name to the provenance of the file it refers to?

%Mathieu: the input parameter is configuration, the used entity is... used.




\subsection{Links with the ProvONE data model}

The IVOA Provenance DM includes several concepts that can be the starting point to define and execute scientific workflow-based computational experiments. In this context, the provenance information could be translated and further developed following the ProvONE ontology and data model \citep{ProvONE}, that was developped as an extension to W3C PROV-DM \citep{std:W3CProvDM}. A general mapping is presented in Table~\ref{tab:provonemapping}.

ProvONE extends W3C PROV with classes and relation that could also be used to extend the IVOA Provenance DM. For example, the relation \class{wasPartOf} between a parent and a child entity can be used to describe the structure of \class{Execution} instances, in that a parent \class{Execution} (associated with a \class{Workflow}) has child \class{Executions} (associated with \class{Programs} and subworkflows). In the same way, the \class{hasSubProgram} relation specifies the recursive composition of \class{Programs}, i.e. a parent \class{Program} includes a child \class{Program} as part of its specification.

\begin{table}[ht]
\centering
\small
\tymax  0.5\textwidth
\begin{tabulary}{1.0\textwidth}{LL}
\toprule
\head{Provenance DM} & \head{ProvONE DM} \\
\midrule
Activity               & Execution       \\
ActivityDescription    & Program          \\
ActivityDescription    & Workflow         \\
UsedDescription           & Port         \\
WasGeneratedByDescription & Port         \\
\bottomrule
\end{tabulary}
\caption[Mapping between classes from ProvONE DM to classes in ProvenanceDM]{Mapping between classes from ProvONE DM to classes in ProvenanceDM. This list is not complete.}
\label{tab:provonemapping}
\end{table}

