Data Model: Unresolved Issues

PIDS

The current format is not final. Has been marked thus in the DataModel
Namespaces and language: All relations are namespaced like the rest of the repository. We use the doms:whatever_u_like namespace for now for all objects and <collection>:whatever_u_like for relations. We want to use a standard naming convention, and we want a decision on language (the doms base collection uses English for both FoxML file names, PIDs and relations; the other example collection are inconsistent).
- Written a proposal on the naming of things in the DataModel. Not final -- abr

In the current data model Type Image defines relation hasFile to a File Object with relation isFileFormat to a TIFF Fileformat Object. Since we allow Fileformat subtyping, we actually mean to a TIFF Fileformat object or a subtype of this. This makes validation difficult. Instead we could subtype Type File to Type TIFF File and Type Image could define relation hasFile to a TIFF File Object. This introduces more Type Objects, and it seems that the file formats are modelled twice... We need a decision.
- I opt for the more difficult validation. When we need to validate types, we are faced with the same problem of following relations to make sure. Subclassing are just a way of hardcoding the relation into the type, so you must follow the "isObjectType" once instead of the "extendsFormat" a few times. --abr
Decided thus

We are still missing descriptions of type, rights and technical datastreams. These are necessary to define for the validation iteration.
Rules for preservation of existing PIDs as metadata when ingesting - where and how?
We have no model of ordered grouping (e.g. pages in a book)... Namespace solution / fragmentation solution ?

We need a guide for creating the metadata model for new collections. For example in the Gentofte project, is the manufacturer a field on the revy object, or a reference on the revy object to a manufacturer project? The Kowari index (MISSING LINK) makes this somewhat irrelevant, but without that it becomes paramount -- ["mke"] DateTime(2007-11-13T09:17:07Z)

DC subject: Idea for clever use: When requesting the subject of an object, follow the chain of parent-objects to the top and concatenate all subjects. See hasConceptualParent later in the RDF section.
Ideas for future use: hasConceptualParent <PID for an object>BRPractical use is for indexing the subject, which is a concatenation of the current object's dc:subject and the conceptual parent's subject. The chain of conceptual parents always ends with project. Cyclic references aren't allowed.