Yes, a slightly more concise version of this response would make an excellent FAQ question.
Cheers, T. ====================================================================== Tony Gill, ArtSTOR Director of Metadata The Andrew W. Mellon Foundation, 140 East 62nd Street, NY, 10021, USA t1 (direct): +1 (646) 274-2265, t2: +1 (212) 838-8400 w: http://www.mellon.org, f: +1 (212) 223-2778 > -----Original Message----- > From: martin [mailto:[email protected]] > Sent: Wednesday, 09 October, 2002 6:58 AM > To: [email protected] > Subject: [crm-sig] Uniqueness of property names in the CRM. > > > Dear All, > > I had the following question about the CRM, I think it is a good FAQ. > Please let me know, if you disagree with my explanations: > > >I am curious about the lack of uniqueness in the naming of > CRM properties. > > > > >(1) You have a single ID for each property, covering both > directions, eg P9 = consists of (forms part of). In RDD we > assign IDs to both directions, as they are semantically distinct. > > > This is a philosophical topic. For us, both directions belong > to the same, directed > property. We do not accept models for the scope of the CRM, > that use one-way links. > For us, if there is a link, it can always be read in two > directions, normally like > active and passive voice. We can discuss more about that. Not > all models regard both > directions as semantically different. E.g. UML assigns two > names, as we do. > > > > > >(2) Property names are also not unique (eg "consists of" > for P5, P9, P45 and P88). > > > The property is unique by the number, not by the name. Names > are mnemonics, > not meant to convey meaning but to remind the meaning. The > CRM is intended to > be international, not English. In a translation, mnemonics > are exchanged, > numbers persist. > > > > > > >There does not seem to be any strict consistency in the > definitions of properties with the same name, or of the > pairings of names: eg > > > > P5 Condition State consists of (forms part of) > Condition State > > > > P9 Period consists of (forms part of) > Period > > > > P45 Physical Stuff consists of (is incorporated > in) Material > > > > P46 Physical Stuff is composed of (forms part > of) Physical Stuff > > > > so I assume there are no underlying abstract properties or > verbs which unite them? > > > Underlying abstract properties are given explicitly by > "subproperty of" statements, > and are not linguistically implied. In cases of pure > restriction, as the > "identified by" series, the same name is used deliberately. > The mnemonic is always > chosen to give a better reading in context. P5, P9 and P45 > never co-occurr, because the > entities are disjoint. > > The mnemonics work well to replace properties in data by quasi- > natural language. This is very beneficial to convey the model > to non-computer experts. > We are more interested in how an instance looks like under > the CRM schema, than how the > CRM schema looks like as a total. This is also due to the > fact, that the CRM is not designed > as data entry tool, where users would need to select > properties,(and may be confused by > multiple occurrence of the same name) but for transformation of > data under local data structures into a common form. > > We deliberately did not assume a common "part-of" theory. > There are too many different > axioms, even for material objects, so that "part-of" seems > rather to be on a meta-meta-level. > Particularly, a common part-of of disjunct concepts would > introduce "unintended models". > Periods, e.g. can't consist of Physical Stuff ! > > > > > > >This creates some difficulties in mapping to other schemas, > as it means there is no unique single name, for example, for > "consists of" as a property linking Physical Stuff and > Material. I can see > >that this is manageable when using CRM as a reference > model, but I wonder if you have considered the implications > for mapping? > > > We do have. Map to the identifier. Use the names as > representation labels. > > > > >I have been doing some test mappings, and I have simply > used (for example) "P9a" and "P9b" to distinguish the > directions of properties. The non-unique textual names do not > then cause an >absolute > problem, although it is confusing to have elements with > identical headwords. > > > If you read our RDFS version, you will see the same. Due to > an ugly assymetry > in RDF use of properties, we are forced to declare forward > and backward > properties as distinct, even though in RDFS they are symmetric. > > We propose: P9F, P9B for those models, that cannot deal with > bidirectional > properties. That allows to recover the common meaning at any > useful time. > > > > > >Have I understood this correctly, or missed something? Can > you explain your thinking on this? > > > To make the point more clear: If Martin "is son of" Wolfgang, > Wolfgang "has son" Martin. > This is a coimplication. Hence, there are not two independent > concepts. Do you > have other concepts in mind? > > Please let me know, if this makes sense, or if I have missed > something. > > ====================================== > > BTW, the latest version of the CRM is now available as RDFS. > Please test. > (http://cidoc.ics.forth.gr/docs/xml_to_rdfs/CIDOC_v3.3.2.rdfs). > It is machine generated, so I hope it is free of spelling errors. > > best, > > Martin > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(810)391625 | > Principle Researcher | Fax:+30(810)391609 | > Project Leader SIS | Email: [email protected] | > | > Information Systems Laboratory | > Institute of Computer Science | > Foundation for Research and Technology - Hellas (FORTH) | > | > Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece | > | > Web-site: http://www.ics.forth.gr/isl | > -------------------------------------------------------------- > >
