Differences

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

--- domain_model [2011/03/02 15:18] – [How do we describe Description Sets and Annotation Sets?] daniel
+++ domain_model [2011/03/29 22:50] (current) – [RDF Implementation] michael
@@ Line 6: / Line 6: @@
 {{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 54: / Line 50: @@
 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.
-===== How do we describe Description Sets and Annotation Sets? =====
+===== 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.
-As we have introduced before, this vocabulary is an extension profile for the DCAM. Therefore, the vocabulary used to assert the annotations to a description set is Dublin Core Vocabulary (since it allows to state the creator, creation date, sources, contributors, etc.). For more information, see the [[use_cases|Use Cases]].
+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?