This is an old revision of the document!
Table of Contents
Domain Model
Final first draft version, agreed upon January 26, 2011:
Namespaces:
- dcprov : Namespace of the domain model. To be defined
Classes:
- Description Set (from DCAM terminology): A set of one or more descriptions, each of which describes a single resource.
- Description (from DCAM terminology): One or more statements about one, and only one, resource.
- Statement (from DCAM terminology): An instantiation of a property-value pair made up of a property URI (a URI that identifies a property) and a value surrogate.
- Annotation: One or more statements about one description set.
- Annotation Set: A set of one or more annotations.
The domain model shown in the diagram is going to form the basis of an application profile for metadata provenance. The main purpose of the UML diagram is to illustrate
- how the new annotation entity (i.e., the entity comprising metadata provenance information) relates to the existing entities of the Dublin Core Abstract Model (DCAM), and
- how an annotation is associated with the metadata it provides information about.
At this point, the domain model does not attempt to describe the makeup of an annotation set in the specific context of metadata provenance, i.e., it does not yet provide an element vocabulary needed to put together a concrete metadata provenance annotation set. At the moment, it only provides the generic scaffolding to accommodate such an element vocabulary.
What a metadata provenance annotation?
As stated in the UML diagram, annotation and annotation sets are primarily specifications of their DCAM counterparts, i.e., subclasses in the RDF model. Just like a description set is an aggregation of descriptions (statements about a single resource), an annotation set is an aggregation of annotations. (We only assume a different cardinality of this relationship, the motivation of which will be explained below.)
This means that every annotation set is also a description set in the sense of the DCAM, and can be treated as such. So why not just stick with the DCAM entities?
The motivation of deriving subclasses in the first place was that the main rationale of an annotation is to provide information about a description set, i.e., about metadata, a specific kind of resource.
Also, the annotations created in the context of the DC-Provenance Application Profile try to provide not just any kind of information about metadata, but a specific kind: information about the provenance of the described metadata.
What does a metadata provenance annotation describe?
Annotations are associated only with description sets. Description sets contain one or more descriptions. The relationship between annotations and description sets (the “role” of annotations in UML terms) is generically stated as being descriptive. The concrete mechanism or relationship employed here will depend on the metadata or resource description model used in a specific metadata application or use case (e.g., RDF).
The cardinality of 1 on the side of the description set indicates that an annotation must only be related to a single description set. It cannot be associated to more
Annotations are aggregated in annotation sets.
The first row reiterates the entities of the DCAM. The second row of the domain model contains the new classes required by the metadata provenance application profile, which in itself are specifications of their corresponding DCAM counterparts.
What is the third level?
Because a AS is a DS, that means that an A can be used to capture prov inf of another AS!
Issues and further Ideas
- Superclass of Description Set necessary? Domain/range problems in OWL, could be circumvented by property/chain inclusion?
