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>

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.

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

Mandatory relations for other objects

Ideas for future use

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.

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?

SB DOMS object structure (last edited 2010-03-17 13:12:57 by localhost)