Child pages
  • Designing data models for DOMS
Skip to end of metadata
Go to start of metadata

Basic concepts

Primitive elements of DOMS data

All data in DOMS is organised in objects. One object may be used to describe all aspects of some entity you wish to describe in DOMS.

Data in an objects is organised in datastreams. A datastream may be a block of XML or a reference to an external binary stream.

Objects may refer to other objects using relations. A relation is a named link from one object to another.

Formal definitions of DOMS data

DOMS described the structure of objects using formal definitions of what objects contain, and how they relate to each other.

Each object subscribes to one or more content models. A content model describes the datastreams of an object, defining allowed mimetypes and XML schemas for the xml datastreams, and also defining valid and required relations using a subset of OWL Lite. A content model also describes how objects of this type may be grouped with other objects to present a named view.

A set of content models describing the different allowed objects for a collection is called a data model.

DOMS enforces that objects are valid for specific content models. Each object maintains a state. Validity is only enforced for objects that have the state active. This allows you to build partial objects in the state inactive, and then publishing them (marking them as active) once they are complete and valid.

Structure of DOMS data

Relations that define special properties of objects in DOMS

Every object should have at least one relation with the name "http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection" to a collection object with the content model "doms:ContentModel_Collection". This relation defines what collections the object is part of.

Every object should have exactly one relation with the name "http://doms.statsbiblioteket.dk/relations/default/0/1/#hasLicense" to a license object with the content model "doms:ContentModel_License". This relation should be duplicated by each object having a POLICY datastream that refers to the LICENSE datastream of the same object by URL.

If an object has a relation "http://doms.statsbiblioteket.dk/relations/default/0/1/#isTemplateFor" to a content model, this defines that it is a template object for that content model. Template objects are prototypes, used to clone to generate new objects.

If a content model has a relation "http://ecm.sourceforge.net/relations/0/2/#extendsModel" it means that objects subscribing to this content model also subscribe to the content model referred to. Due to limitations in Fedora, it is still necessary, however, to mention both content models in subscribing objects, and this relation must therefore be considered unsupported.

Special objects in DOMS

Collection objects are objects of content model "doms:ContentModel_Collection". They contain any data about a collection.

License objects are objects of type "doms:ContentModel_License". They must contain a datastream "LICENSE" with an XACML-description of access rights to objects referring to this license. They may also contain any other metadata about the license.

File objects are objects of type "doms:ContentModel_File". They must contain a datastream CONTENTS that refers to a binary file by URL. They must also contain a datastream CHARATERISATION that contains characterisation information for the file (the specification for this is still under development). Specialisations of this datamodel should contain specialisations of the allowed mime types for the CONTENT datastream. File objects should describe technical aspects of files, but not bibliographic metadata. This will allow migration of a file without having to update the bibliographic metadata objects.

Designing a datamodel

To design at datamodel for a collection in DOMS, the following workflow is suggested:

  • Identify files in the collection.
  • Identify bibliographic objects. It may be relevant to think of elements of FRBR and object oriented modelling at this stage.
  • Draw the diagram as interconnected boxes for each element.

Example:

Abstract model

  • For each line in the diagram, define a name and a direction for the relation. Note that standards may exist for common relations.
  • For each box in the diagram, define what datastreams should exist, with what XML schema

Example:

Realized model

  • For each object, identify the license for accessing the object
  • Identify whether, and how, some blocks in the diagram should be grouped when disseminating objects.

Full model

Implementing a datamodel

Once the datamodel has been designed, the model can be implemented in DOMS. The following workflow is suggested:

  • For each object in the diagram, create a content model object. In that content model object:
    • For each datastream
      • Define the datastream in the DS-COMPOSITE-MODEL datastream of the content model
      • If the datastream is an XML metadata datastream, refer to the XML schema in the DS-COMPOSITE-MODEL
      • If the datastream is an externally referenced binary stream, define the allowed mime types
    • For each outgoing relation
      • Define the relation in the ONTOLOGY datastream if the content model
      • Define the cardinality of the realtion (how many relation may/must be present of this type)
      • Define the content model of the object of this relation (what kinds of objects may we refer to)
  • For each identified view
    • In the content models for this view, define the entry objects in the RELS-EXT datastream and the relations that define the angles in the VIEW datastream.
  • For each different license for the collection
    • Define a LICENSE object
    • Express the license in XACML in the LICENSE datastream.
  • Create a collection object
  • For each object in the diagram
    • Create one or more template objects, containing a prototype of the object. Templates should always be inactive.
    • Add prototypes of the inline XML datastreams

TODO: Insert examples

  • No labels