domain_model
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
domain_model [2011/02/02 14:59] – michael | domain_model [2011/03/29 20:50] (current) – [RDF Implementation] michael | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Domain Model ====== | ====== Domain Model ====== | ||
- | Final first draft version, | + | 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 |
+ | |||
+ | 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|}} | {{domain-model-classes3.png|}} | ||
- | Namespaces: | + | The proposed model extends the [[http:// |
- | * dcam ([[http:// | + | |
- | * dcprov | + | |
- | Classes: | + | |
- | | + | * Description (from [[http:// |
- | * Description (from [[http:// | + | |
* Statement (from [[http:// | * Statement (from [[http:// | ||
- | * Annotation: One or more statements | + | * Annotation: One or more -> Statements |
- | * Annotation Set: A set of one or more annotations. | + | * Annotation Set: A set of one or more -> Annotations. Subclass of -> Description Set. |
+ | |||
+ | The DC-PROV domain model 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// | ||
+ | |||
+ | ===== What is a metadata provenance annotation? ===== | ||
+ | |||
+ | As stated in the UML diagram, Annotation and Annotation Sets are primarily specifications of their DCAM counterparts, | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | ===== What does a metadata provenance annotation describe? ===== | ||
- | The domain model shown in the diagram is going to form the basis of an application profile for metadata provenance. Its main purpose | + | Annotations are associated only with Description Sets. Description Sets contain one or more descriptions. |
- | The first row reiterates | + | The " |
- | ====== Earlier versions | + | 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 |
- | Version based on telco of Dec 22th: | + | 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 |
- | {{https:// | + | 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. |
- | Source files ([[http:// | + | In addition, this constraint ensures that Annotations can be further annotated by associating higher-level Annotations with a lower-level Annotation Set. |
- | * https:// | + | |
+ | @@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. | ||
- | Version based on the telco of Dec 15th: | + | ===== Vocabulary for the Annotations ===== |
- | {{https:// | + | It has to be distinguished between the vocabulary that is introduced by the Domain Model (dcprov: |
- | {{https://dl.dropbox.com/ | + | |
+ | 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. | ||
- | Source files ([[http:// | + | ====== RDF Implementation ====== |
- | * https:// | + | |
- | * https:// | + | |
- | ---- | + | 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. |
- | Previous drafts: | + | # Named graph: http:// |
+ | @prefix dct: < | ||
+ | @prefix dctype: < | ||
+ | |||
+ | :MonaLisa dct:format dctype: | ||
+ | dct:creator : | ||
+ | # Named graph: http:// | ||
+ | @prefix dct: < | ||
+ | | ||
+ | < | ||
+ | dct:creator :BnF . | ||
+ | | ||
+ | < | ||
+ | | ||
+ | These triples describe two separate RDF graphs. | ||
+ | | ||
+ | {{: | ||
- | {{https:// | + | The following table shows how some of the RDF resources map to their corresponding UML classes |
+ | ^ RDF ^ UML | ||
+ | | :MonaLisa dct:creator : | ||
+ | | < | ||
+ | | < | ||
+ | | < | ||
- | Source files ([[http://www.yworks.com/ | + | Our example consists of two statements about the resource '' |
- | * https:// | + | |
- | * https:// | + | |
- | A comparison model for discussion | + | Statements that are part of this graph are considered annotations, |
+ | ====== Issues and further Ideas ====== | ||
+ | * Superclass of Description Set necessary? Domain/ | ||
- | {{: | ||
domain_model.txt · Last modified: 2011/03/29 20:50 by michael