= 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 :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]] <> == 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 <
>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.