Very much a work-in-progress.
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)
There are three basic objects in the DOMS:
Grouping of one or more elements of the same type.
A representation of a whole.
The smallest element in the DOMS. An atom does not contain other objects.
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
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.
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.
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?
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.
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.
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.