Very much a work-in-progress.

Identifiers

In theory, the identifier for a DOMS can be an unique random string of characters. In reality, having identifiers like "CD:Gnags_Ref1234" makes it easy for humans to recognize objects.

It is expected that the DOMS will contain objects from several different projects. Each project will be assigned a short string, that will be the first part of identifiers for objects from the project. Each project should create human-readable identifiers, based on the provided part.

Example: The project MovieCommercials are assigned "mc". The objects from the project are assigned the identifiers

• mc:Project (group with all MovieCommercial entities. This object also contains detailed description of the project)

• mc:Group_<integer> (group with some MovieCommercial_<integer> entities)

• mc:Commercial_<integer> (entity representing a single commercial)

• mc:Movie_<integer> (atom representing the movie in question)

• mc:CensorCard_<integer> (atom representing a censor card)

Objects

There are three basic objects in the DOMS:

• Group
  Grouping of one or more elements of the same type.

• Entity
  A representation of a whole.

• Atom
  The smallest element in the DOMS. An atom does not contain other objects.

Group

Groups are collections of other groups and entities. Objects are added to a group by referencing the group. The references are uni-directional for performance-reasons.

Todo: Look at the RDF specification for containers: http://www.w3.org/TR/rdf-primer/#containers

Ordered grouping

If we want an ordered grouping, we cannot rely on references from the objects, belonging to the group. Instead we introduce hasOrderedMember and let the order of hasOrderedMember-relations determine the presentation order.

Problem

What do we do, when we want a single group to define more than one ordered grouping? an example:

We want to represent a book from the project "Vort sogns Historie". A book contains pages, which have to be presented in order. The collection of information, that a book represents, also contains Sogne, which could also require an order-orientated presentation.

This is related to Metadata on references.

Namespace solution

We could do it by namespace:

hasOrderedMember: page1
hasOrderedMember: page2
...
hasOrderedMember: page123
hasOrderedMember: sogn1
hasOrderedMember: sogn2
...
hasOrderedMember: sogn12

If we know that page and sogn is two different things, we can devide the two ordered groups. If we do not know that, then they will be presented as a single ordered list. Can we live with that?

Fragmentation solution

We could create objects which are simply groups, so that a book would reference a Pages object, which would only contain a list of references to pages.

Entity

Atom

Project

Projects can be viewed as entities. There's no strict need for an object representing a certain project in Fedora, but it makes maintenance easier. Project-objects contains a verbose description of the project, persons involved, standards, conventions, workflow and such. It would be nice to be able to edit this Wiki-style.

Attributes

Brainstorming here - even less substantial than the above.

• Migrate (Free|Bound|Immutable)
  • Free: This object can be migrated to another format with no fear of breaking dependencies from other objects.
  • Bound: This objects is referenced by other objects. The references might break upon migration.

  • Immutable: This object is not to be migrated. An example could be a library, referenced by a LaTex-document.