[crm-sig] Uniqueness of property names in the CRM.
TG at mellon.org
Tue Oct 15 17:54:00 EEST 2002
Yes, a slightly more concise version of this response would make an
excellent FAQ question.
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:martin at ics.forth.gr]
> Sent: Wednesday, 09 October, 2002 6:58 AM
> To: crm-sig at ics.forth.gr
> 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)
> > 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
> 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
> BTW, the latest version of the CRM is now available as RDFS.
> Please test.
> It is machine generated, so I hope it is free of spelling errors.
> Dr. Martin Doerr | Vox:+30(810)391625 |
> Principle Researcher | Fax:+30(810)391609 |
> Project Leader SIS | Email: martin at ics.forth.gr |
> 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 |
More information about the Crm-sig