Differences

This shows you the differences between two versions of the page.

--- domain_model [2011/02/16 15:45] – kai
+++ domain_model [2011/03/29 22:50] (current) – [RDF Implementation] michael
@@ Line 1: / Line 1: @@
 ====== Domain Model ======
-This page contains the description and documentation of the domain model that is proposed by the DC-Provenance task group. It is not yet finalized and currently regarded as work in progress. See the revision history of this page for earlier drafts. The group members agreed on the basic model that is preented here on January 26, 2011.
+This page contains the description and documentation of the domain model that is proposed by the DC-Provenance task group. It is not yet finalized and currently regarded as work in progress. See the revision history of this page for earlier drafts. The group members agreed on the basic model that is presented here on January 26, 2011.
 The main part of the current model is the definition of the classes and their relations, as illustrated in the following UML class diagram:
 {{domain-model-classes3.png|}}
-Namespaces:
-  * dcam ([[http://dublincore.org/documents/abstract-model/|Dublin Core Abstract Model]]): http://dublincore.org/2010/10/11/dcam.rdf#
-  * dcprov : Namespace of the domain model. To be defined.
 The proposed model extends the [[http://dublincore.org/documents/abstract-model/|Dublin Core Abstract Model]]. Particularly, we use the following classes:
@@ Line 41: / Line 37: @@
 The "describes" relationship in the diagram must not be confused with properties in RDF. In an RDF implementation, the "describes" relationship would just be the fact that the Description Set is used as a subject in the triples that form the Annotations.
-The cardinality of 1 on the side of the Description Set indicates that an Annotation must only be related to a single Description Set. The same Annotation cannot be associated with more than one Description Set; firstly, in order to be compliant with the DCAM definition of Description ("Statements about one, and only one, resource") which Annotation is derived from, and secondly, to make expressions of the domain model in metadata frameworks like RDF easier, where one Annotation about two different Description Sets would result in two completely different triples.
+The cardinality of 1 on the side of the Description Set indicates that an Annotation must only be related to a single Description Set. The same Annotation cannot be associated with more than one Description Set for two reasons; firstly, to be compliant with the DCAM definition of Description ("Statements about one, and only one, resource") which Annotation is derived from, and secondly, to make expressions of the domain model in metadata frameworks like RDF easier, where one Annotation about two different Description Sets would result in two completely different triples.
-Annotations are aggregated in Annotation Sets, just as Descriptions are generally aggregated in Description Sets.
+Annotations are aggregated in Annotation Sets, just as Descriptions are generally aggregated in Description Sets. The main difference between these lies, once more, in cardinality. Whereas the association of a Description with a Description Set is optional, this does not hold for the association between an Annotation and an Annotation Set. An Annotation has to be part of at least one Annotation Set; conversely, every Annotation Set aggregates at least one Annotation.
-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.
+The rationale for this cardinality constraint is mainly to enable basic discoverability of Annotations. Since (1) a variety of relationships are used for annotating description sets, and (2) not all entities associates in that manner with a Description Set may be metadata provenance related, the Annotation Set provides a general means of retrieving metadata provenance information.
+In addition, this constraint ensures that Annotations can be further annotated by associating higher-level Annotations with a lower-level Annotation Set.
+@@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 an Annotation Set is a Description Set, an Annotation Set can itself be annotated by means of a further Annotation Set, i.e. we can capture provenance information for Annotation Sets as well. The model is able to handle an arbitrary number of meta-levels.
+===== Vocabulary for the Annotations =====
+It has to be distinguished between the vocabulary that is introduced by the Domain Model (dcprov: namespace) and the vocabulary that is used to create the actual annotations. In the latter case, the common Dublin Core Vocabulary (dcterms) is used to state provenance information like creator, creation date, sources, contributors, etc. For more information, see the [[use_cases|Use Cases]].
+The model for sure allows the use of arbitrary vocabularies as annotations and the mix of Dublin Core and other Vocabularies is perfectly ok, in the same way as it is common practice in usual application profiles.
+====== RDF Implementation ======
+The abstract domain model has to be expressed to elements offered by a specific data model to be useful. The following illustrates a way to annotate RDF (meta-)data with provenance annotation.
+  # Named graph: http://example.org/data/ML-Desc
+  @prefix dct: <http://purl.org/dc/terms/> .
+  @prefix dctype: <http://purl.org/dc/dcmitype/> .
+  :MonaLisa dct:format dctype:StillImage ;
+      dct:creator :LeonardoDaVinci .
+  # Named graph: http://example.org/data/ML-Anno
+  @prefix dct: <http://purl.org/dc/terms/> .
+  <http://example.org/data/ML-Desc> rdf:type dcam:DescriptionSet ;
+      dct:creator :BnF .
+  <http://example.org/data/ML-Anno> rdf:type dcprov:AnnotationSet .
+These triples describe two separate RDF graphs.
+{{:rdf-model.png|}}
+The following table shows how some of the RDF resources map to their corresponding UML classes of the domain model.
+^ RDF      ^ UML       ^
+| :MonaLisa dct:creator :LeonardoDaVinci .  | Description  |
+| <ML-Desc>  dct:creator :BnF . | Annotation |
+| <ML-Desc>    | Description Set |
+| <ML-Anno>    | Annotation Set |
+Our example consists of two statements about the resource '':MonaLisa'', one about authorship of the resource, the other about its format. The graph ''<ML-Desc>'' containing these statements forms a Description Set. Annotations about this metadata are contained in a second graph, ''<ML-Anno>'', forming an Annotation Set.
+Statements that are part of this graph are considered annotations, i.e., statements about the provenance of the //metadata// of the original resource '':MonaLisa'', not the resource itself. The statement ''<ML-Desc> dct:creator :BnF .'' would mean that the Bibliothèque nationale de France created the description of the :MonaLisa (i.e., the metadata) contained in the graph ''<ML-Desc>'' as opposed to the creation of the :MonaLisa itself.
 ====== Issues and further Ideas ======
    * Superclass of Description Set necessary? Domain/range problems in OWL, could be circumvented by property/chain inclusion?