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

Validation of relations

• 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

Object Structure

• 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 ?

New:

• 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 2007-11-13 09:17:07

Ideas

• 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>
  Practical 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.