|
Size: 913
Comment:
|
← Revision 12 as of 2010-03-17 13:09:04 ⇥
Size: 1984
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Line 4: | Line 3: |
| The DOMS system will be a system that models several collections of digital objects. Each object belongs to one or more collections. This is represented by having one or more "isPartOfCollection" relations to the parent collections. This goes for a collection object as well - it belongs to another collection. One collection has special status though: the "doms:Root_Collection" does not belong to any other collection, and is thus the bottom element for the "isPartOfCollection" relation. Every other collection has a "isPartOfCollection" relation to "doms:Root_Collection". | Those trained by the academic tradition of the western world like to think in terms of categories and collections. Categories in Fedora are modelled by the Content Models, but there is no system in place for Collections. But Fedora allows for RDF relations between objects, and with that we can easily model collections. |
| Line 6: | Line 5: |
| In addition, DOMS contains another special collection - the "doms:DOMS_Base_Collection". This collection provides objects such as content models and licenses that are utilized by (and mandatory for) the other collections in the DOMS. This collection is meant to be ingested as the first collection in the DOMS. | There is no inherent semantic meaning attached to collections. They are a way to group objects, pertaining to some criteria. Content Models are also part of collections, preferably the collections containing objects that use them. Template objects are also part of collections. A special collection [[DataModel/DOMS Base Collection| doms:DOMS_Base_Collection]] contains the base objects of the DOMS system, described in DataModel. This collection will always be present. == The Collection Hierarchy == In the doms-relations namespace (see DomsNameSpacesAndSchemas) we define a reserved relation "isPartOfCollection". All objects must have at least one such relation to a Collection object (ie. an object of [[DataModel/ContentModel Collection| doms:ContentModel_Collection]]). This includes the collection objects themselves, and as such there is a hierarchy of collections. At the top, we have defined a special collection object, called [[DataModel/Root Collection| doms:Root_Collection]]. This collection contains itself. Collections can contain other collections, but cycles in the graph is explictly forbidden. The only accepted cycle is the root collection that contain itself. Aside from forbidding cycles, there are no requirements for the structure of the graph. We envisage two ways to use collections 1. As a strict hierarchy, modelled on the organisational structure and the areas of responsibility. Few collections, and objects are not part of many collections. 1. As a way of adding tags (subjects) to the objects. There will be many collection objects, and objects will be part of many collections. |
Collections
Those trained by the academic tradition of the western world like to think in terms of categories and collections. Categories in Fedora are modelled by the Content Models, but there is no system in place for Collections. But Fedora allows for RDF relations between objects, and with that we can easily model collections.
There is no inherent semantic meaning attached to collections. They are a way to group objects, pertaining to some criteria.
Content Models are also part of collections, preferably the collections containing objects that use them. Template objects are also part of collections.
A special collection doms:DOMS_Base_Collection contains the base objects of the DOMS system, described in DataModel. This collection will always be present.
The Collection Hierarchy
In the doms-relations namespace (see DomsNameSpacesAndSchemas) we define a reserved relation "isPartOfCollection". All objects must have at least one such relation to a Collection object (ie. an object of doms:ContentModel_Collection). This includes the collection objects themselves, and as such there is a hierarchy of collections.
At the top, we have defined a special collection object, called doms:Root_Collection. This collection contains itself. Collections can contain other collections, but cycles in the graph is explictly forbidden. The only accepted cycle is the root collection that contain itself.
Aside from forbidding cycles, there are no requirements for the structure of the graph. We envisage two ways to use collections
- As a strict hierarchy, modelled on the organisational structure and the areas of responsibility. Few collections, and objects are not part of many collections.
- As a way of adding tags (subjects) to the objects. There will be many collection objects, and objects will be part of many collections.