'''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<<BR>>Grouping of one or more elements of the same type.
   * Entity<<BR>>A representation of a whole.
   * Atom<<BR>>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.