It's probably a good idea to take a look at the reference example from fedora.info: http://www.fedora.info/download/2.0/userdocs/digitalobjects/foxml_reference_example.xml

Introduction

In the SB DOMS, there are different projects. A project always has a root object, that contains information about the project itself.

Object properties

This is the first part of Fedora objects are non-versionable and should thus not be changed. Exceptions to this rule is the "deletion" of objects, which marks them as deleted, and lastModified, which is automatically updated.

<foxml:objectProperties>
<foxml:property NAME="http://www.w3.org/1999/02/22-rdf-syntax-ns#type" VALUE="FedoraObject"/>
<foxml:property NAME="info:fedora/fedora-system:def/model#state" VALUE="A"/>
<foxml:property NAME="info:fedora/fedora-system:def/model#label" VALUE="Permanent label"/>
<foxml:property NAME="info:fedora/fedora-system:def/model#contentModel" VALUE="SB"/>
</foxml:objectProperties>

• The type will always be a FedoraObject (the only other legal values are behaviour definitions and mechanisms).

• The stats will always start as "A" for Active.
• The label is used for admin access to Fedora, which means that poor labels are only an annoyance, not a real problem.
• The contentModel is always "SB", which isn't very descriptive. This is due to the non-versionable nature of the object properties: We don't want to freeze more than we have to and thus reproduce the contentModel in the dc:format field instead.

Dublin Core

This is the only datastream, that has to be present in a Fedora object. It is anticipated that the SB DOMS will extend on the DC standard, to accommodate local requirements.

Unfortunately, Fedora does not support qualified Dublin Core. Elements can still be duplicated, though.

Dublin Core contains 15 elements. The official definitions at http://dublincore.org/documents/dcmi-terms/ are, by design, very vague. The SB DOMS has stricter definitions.

• title

  • Project-objects: The title for the project. Example: "Vort sogns historie".

  • Other objects: As defined by DCMI.

• creator

  • Project-objects: The entity responsible for this project. In most cases, this will be "Statsbiblioteket".

  • Other objects; As defined by DCMI.

• subject

  • Project-objects: Keywords from the current SB controlled vocabulary.

  • Other objects; Project-specific.

  • Idea for clever use: When requesting the subject of an object, follow the chain of parent-objects to the top and concatenate all subjects. See hasConceptualParent later in the RDF section.

• description

  • Project-objects: As defined by DCMI, but only short text, no images.

  • Other objects; As above.

• publisher

  • Project-objects: The entity publishing this project. This will probably always be Statsbiblioteket.

  • Other objects; As defined by DCMI.

• identifier

  • Project-objects: Project-specific access-point, specified by URL. Example: http://vortsognshistorie.dk

  • Other objects; The object in project-specific context, specified by URL. Example: http://vortsognshistorie.dk/record.jsp?ref=040293&browse=yes

• type - http://dublincore.org/documents/dcmi-type-vocabulary/

  • Project-objects: "collection" (taken from DCMI) and "project" (from SB DOMS controlled vocabulary).

  • Other objects; One type, as defined by DCMI, one or more types from SB DOMS controlled vocabulaty.

  • Note: See SB DOMS type vocabulary. We do not want project-specific types, as they are handled by the project-specific presentation, referred by the dc:identifier.

• contributors
  We're unclear on this one. Maybe it won 't be used.

• language - http://www.ietf.org/rfc/rfc3066.txt http://www.w3.org/WAI/ER/IG/ert/iso639.htm

  • Project-objects: .The overall-language for the project. This will often be danish ("da").

  • Other objects; As defined by DCMI.

• relation
  We're unclear on this one. Maybe it won 't be used.

• date - http://www.w3.org/TR/NOTE-datetime

  • Project-objects: Start date for the project in DOMS-context.

  • Other objects; Start date for the object in DOMS-context.

  • Note: Metadata for dates, regarding the content, are to be stored in dc:coverage.

• format

  • Project-objects: SB DOMS specific, referenced by PID.

  • Other objects; SB DOMS and project-specific, referenced by PID.

  • Note: Mandatory. All objects in the DOMS must point to a format, described in the DOMS. This enforces assessement of all resource types, that are to be ingested. See SB DOMS formats.

• source

  • Project-objects: As defined by DCMI, if the project is based on a limited and uniquely identifiable source, else a textual description.

  • Other objects; As defined by DCMI, if the object represents a work or similar. If the object describes part of a work og is fully disconnected from outside sources, a PID to one or more Fedora objects should be used.

• coverage - http://www.getty.edu/research/tools/vocabulary/tgn/index.html

  • Project-objects: As defined by DCMI.

  • Other objects; As defined by DCMI.

• Rights

  • Project-objects: SB DOMS specific, referenced by PID.

  • Other objects; SB DOMS specific, referenced by PID.

  • Note: If no rights are specified, no action is allowed by other persons than administrators. Rights describes access permissions, as well as licence. See SB DOMS rights.

Resource Description Framework

http://www.w3.org/RDF/

In the SB DOMS, the RDF datastream is mandatory. This is dictated in order to avoid rogue objects. An exception to this rule is project-objects, as they act as roots in the hierarchy of objects.

SB DOMS RDF uses the controlled vocabulary from Fedora, together with a generic SB DOMS controlled vocabulary and a project-specific controlled vocabulary. See SB DOMS relations.

Mandatory relations for project objects

• None.

Mandatory relations for other objects

• isPartOfProject <PID for a project object>

Ideas for future use

• hasConceptualParent <PID for an object>
  Practical use is for indexing the subject, which is a concatenation of the current object's dc:subject and the conceptual parent's subject. The chain of conceptual parents always ends with project. Cyclic references aren't allowed.

Generic datastreams

None of the generic datastreams are mandatory in the DC DOMS. If present, they can be used for generic display of DOMS objects.

• PRESENTATION_IMAGE_150x150 Highly recommended: An image used for display in search-results and similar places. Valid image formats are, as of 2006, PNG and JPEG. Pixel size is at most 150x150 pixels.

• PRESENTATION_IMAGE_700x700: An image used for detailed display of an object. Valid image formats are, as of 2006, PNG and JPEG. Pixel size is at most 700x700 pixels.

• PRESENTATION_IMAGE_FULL: An image used for detailed display of an object. Valid image formats are, as of 2006, PNG and JPEG. Pixel size is project specific.

• PRESENTATION_MOVINGIMAGE_PREVIEW: A snippet of a moving image, typically reduced by lowering resolution, framerate, compression-quality and/or length. Valid formats are to be determined.

• PRESENTATION_MOVINGIMAGE: A moving image used for detailed display of an object. Valid formats are to be determined.

• MASTER: The master of the digital object that the Fedora object describes.

Note 1: The sizes in pixels are selected by Toke. We need to discuss these numbers with the webboys. The numbers are explicit in the datastream-id, in order to facilitate name-consistent additional datastreams (e.g. PRESENTATION_IMAGE_32x32 for icon-based access to the DOMS).

Note 2: How do we specify that some people are allowed to see a preview and others are allowed access to the master? Is that solely a job for the dc:rights-element?