\TODO{Include all this into the ``How to use the model'' section.}
\subsection{Links, ids}\label{sec:links_between_data}
It would be convenient, if each data object or even each file 
gets a unique id that can be referenced. The W3C provenance model requires ids
for entities, activities and agents, and they have to be qualified strings, 
i.e. containing a namespace. For example, an activity in the RAVE-pipeline could 
have the id `\texttt{rave:radialvelocity\_pipeline\_20160901}'. Using a namespace for each 
project for these ids will help to make them unique. 

If several copies of a dataset exist, and one of them is corrupted, it would even be useful to know
exactly which copy was used by a given activity. This can be modeled already 
with the existing tools (using a copy-activity), but we doubt that many people
would actually need this level of detail.

IVOIDs, DOI's or ORCIDs are potentially good candidates for unique identifiers.


%\subsubsection{Calibration data}
%The calibration dataset consists of images that can be used to calibrate the
%raw data. It is not necessary to mention them explicitly in the model, 
%they are just another dataset that is used by activities with a 
%calibration-method.

%\subsubsection{Quality}
%For expressing the quality of data, we could simply define additional 
%attributes for each \class{Activity}
%or \class{Entity} object, i.e. zero, one, or more properties in the form of
%key-value pairs. We could use a \class{Quality} namespace to mark a keyword
%as quality-related:
%\begin{itemize}
%    \item quality:comment: [some text]
%    \item quality:seeing: [some value]
%\end{itemize}
%The values could range from a float number to free text.


%\subsubsection{Provenance of provenance}
%``Bundles'' are used to name a set of provenance descriptions. It is a type for 
%an entity, and allows to express provenance of provenance. This is probably  
%very interesting for workflow systems.
% -- partially covered already with ActivityFlow

\subsection{Description classes}
This model was established mainly having a database implementation in mind. 
However, it may be better in the long run to store provenance with 
the entities themselves, e.g. as an additional extension in fits-headers.

A model using description classes for defining templates for activities and
entities has an advantage for normalization: the common processes could be 
described once and for all at some place and then be reused when recording
provenance information for certain entities and activities. This \emph{some place} 
is actually the crucial point here.
In an ideal world, ``some place'' could collect all the descriptions from all 
the possible datasets and methods in astronomy, but building such a look-up place 
is a quite challenging task -- it will probably never be complete. There's also 
the issue of persistent identifiers/broken links to consider.
Normalisation is useful for closed systems, e.g. for describing the provenance 
for data produced by a certain pipeline (e.g. MuseWise system) or with 
workflow tools or when a task needs to be repeated many times. However, the VO 
is quite the contrary of a closed system and we need to keep an eye on what is 
actually achievable.

When writing down a simple serialisation of e.g. the provenance for a stacked 
image using the current model including the description classes, it soon becomes quite cumbersome to define 
everything twice: first the descriptions, then the instances. This basically 
doubles the number of entries to describe provenance (unless there is already 
some place with all the descriptions to which we can refer).

Expressing provenance for a stacked image with this smaller set of classes may 
be simpler, but on the other hand constructing a database schema becomes much 
harder. 
We could leave it to the implementors to choose what is more useful for them.
When extracting a serialisation of the provenance information from a provenance 
service, the attributes of the description classes could be combined with 
the corresponding activity/entity classes. This will produce some repetition
(e.g. many entities may have the same descriptive attributes), but 
avoid having too many classes and links between them.
% Note: Harry Enke commented that this sentence is not understandable; 
% we can remove this sentence later on when we have a proper implementation-note section.
%\Note{Descriptions could be present in W3C-conform serialisations, if we 
%put them into entities.}

%\TODO{Check, if PROV-Templates from the W3C (inofficial note) could be used 
%for ActivityDescriptions.}

\subsection{ActivityFlow and viewLevel}
Since we introduced \class{ActivityFlow} mainly for having different view levels, 
we may want to add an attribute \emph{viewLevel} to the class \class{ActivityFlow}.
However, it is not clear, if viewLevel=0 describes the coarsest or most detailed view.
It may happen, when recording provenance information, that first a pipeline activity 
is defined and only later the detailed steps are described and the pipeline activity is flagged as
an activityFlow with certain steps. Also, when having a detailed description of each activity step, 
one may later decide to group activities together and define an activityFlow. Therefore, it is not
that straightforward to define absolute viewLevel-values. Probably this has to be customized for
each project itself.

