Hi Rob, ...and this is the problem that CRM addresses. This is the problem that everyone uses different vocabularies which has made it difficult for us to integrate data. In contrast, CRM creates a semantic framework of entities for integration. The incorporation of vocab through E55 is a solution, often far better than that actually used in collection management systems that prioritise vocabularies. In a CMS we simply pick a vocabulary term from an authority to populate a field. In other words we implicitly use P2 with authority terms and we add no framework semantics to the field value pairs. e.g. Field:Dimension, Value:height, or for the BM and others, a field label that is hard to decipher.
In CRM, Dimension is explicitly typed and the vocabulary attached to it is typed as Type - we make use of skos through E55 Type (or skos:Concept) - which is a good place for vocabulary. If you incorporated vocabulary terms into the ontology itself then you would simply create the unmaintainable schema that CRM was created to solve. P2 is far better than having specialised vocabulary based properties. We sometimes specialise P2 in rare occasions with a property associated with a particular vocabulary term which is a one off - perhaps to differentiate types applied to the same domain. When we applied specialisation to internal vocabularies (in particular, association vocabulary) we realised that it led to a problem in which the vocabulary started to dominate the ontology schema (large numbers of specialisation of P2 has type) and make it unsupportable without any benefits over and above - P2_has_type >E55 (skos:Concept) > skos:prefLabel. The specialised properties we created from the vocabularies served no practical purpose when comparing vocabulary terms and probably made matters worse. I am happy to send some early examples of this. In comparison in many base systems I see, the additional vocabulary is not even normalised and resides in the same field - something like 20 x 10 (open) or (open lid) or some other vocabulary term. If you look at the Met's recent public data you will see that that have variations of dimension with descriptions in brackets. I think sometimes these are physical features, but appear like this, Dimension: 30H x 10W (base); 20 x 5 (clock face) - and so on. Dimension type, value, unit and additional type reflects CDWA (except with semantics), but in CDWA the only mandated field is "dimension description" (free text). Vocabulary alignment is a separate issue but actually made a little easier by employing a CRM framework first. Best, Dominic orcid.org/0000-0002-5539-3126 On Mon, Apr 3, 2017 at 8:35 PM, Robert Sanderson <[email protected]> wrote: > Thanks Martin :) > > If I understand correctly, both the type of dimension (height vs width) > and the state of the object being measured (lid-open vs lid-closed) would > both end up as external P2_has_type URIs? > > _:h a Dimension ; > label “Height of the box with the lid open” ; > has_type <height> , <lid-open> ; > has_value 14 ; > has_unit <inches> . > > And as the width doesn’t change depending on <lid-open> or <lid-closed> > ness: > > _:w a Dimension ; > label “Height of the box with the lid open” ; > has_type <width> , <lid-open>, <lid-closed> ; > has_value 8 ; > has_unit <inches> . > > It seems a little jarring to have a core museum activity being treated > with (from my perspective) little regard, compared to some of the existing > distinctions made between classes with very little practical value. When > the <height> and <lid-open> URIs are not understood, let alone the unit > URI, the only thing the ontology actually captures is the value… and as E60 > can be a string, there’s not all that much value (ha!) there either. > > When the answer to all questions is “Just put it in P2”, doesn’t that give > one pause that P2 is so broad as to be meaningless? > > Rob > > > On 4/3/17, 12:16 PM, "martin" <[email protected]> wrote: > > Dear Robert, > > The standard way to describe this in the CRM is to type the Dimension > with the procedure: > a) Lid-open > b) Lid-closed > > The Measurement procedure type can be documented by a detailed text. > > In biology, one would measure "wingspan at life" and "winspan dead" of > a > bird, etc. > > Best, > > martin > > On 3/4/2017 7:13 μμ, Robert Sanderson wrote: > > Dear all, > > > > One of our use cases which we are having trouble modeling with just > the core CRM ontology is measurements of an object in a particular state. > For example, we would like to record the measurements of a chest with the > lid open, rather than those with the lid closed. It is the same object, > just in two different states, resulting in different measurements. > > > > The proposed scope note does certainly clarify more than the rather > terse original, but if there is any feedback or guidance as to the above > situation, we would be greatly appreciative. > > > > Many thanks, > > > > Rob > > > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: [email protected] | > | > Center for Cultural Informatics | > Information Systems Laboratory | > Institute of Computer Science | > Foundation for Research and Technology - Hellas (FORTH) | > | > N.Plastira 100, Vassilika Vouton, | > GR70013 Heraklion,Crete,Greece | > | > Web-site: http://www.ics.forth.gr/isl | > -------------------------------------------------------------- > > > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig >
