[Crm-sig] Compatibility document V4

Stephen Stead steads at paveprime.org
Mon Nov 3 16:47:54 EET 2008

1] Time slot is 11.30-13.00 on 6th Nov
2] A more expressive title is a good idea
3] General remark: That is something we should discuss on the 6th
4] No it does not address the workflow. Yes you do have to structure it to
use the CRM.
5] Yes
6] Nick comment here
7] "using" is a rough translation. An expert is somebody who can read both
languages and understand if the statements are equivalent, so most art
historians will not be.
8] Cardinality constraints do not allow for incomplete knowledge or
alternative knowledge. The classic is we have one father but we may know
about 0, 1 or many (different opinions).
9] I do not think we are using consistent in the same way you are.
10] An address management system is not an information system that is in

Out of time now!

Stephen Stead
Tel +44 20 8668 3075 
Mob +44 7802 755 013
E-mail steads at paveprime.com

-----Original Message-----
From: crm-sig-bounces at ics.forth.gr [mailto:crm-sig-bounces at ics.forth.gr] On
Behalf Of Bernhard Schiemann
Sent: 03 November 2008 08:50
To: Crm-sig at ics.forth.gr
Subject: [Crm-sig] Compatibility document V4

Dear all,
Regarding the compatibility document (V4), we have the following questions:
-I found no time slot for this issue during the London meeting. Shouldn't
the SIG discuss and/or vote on that issue in London?

-The term "Compatibility" is used for this document and most of the contents
is about the compatibility between technical systems. (first
sentence: "of their data structures"). Maybe this could be formulated
precisely by changing the headline to e.g.
"CRM compatibility of technical systems and data structures" instead of

A general remark: As the goal seems to be to be to assert compatibility with
the CRM as defined in the CRM document, it is hard to impossible to achieve
this goal as long as we refer to a text which is open for interpretation.
Compatibility in a rigid sense can only be proved with a formal definition.
One could propose a weak concept of compliance if there is a test suite
against which a system claiming that can be tested.  However, what is easier
is to check for incompatibility, i.e. it is far easier to say if something
is incompatible, i.e in contradiction, with the CRM.

-"In other words, it does not aim to provide more structure than users have
previously provided." (Page 1, section 1.1, 3. paragraph) Does this address
the workflow to produce compatible data?
If you have a structure you can translate it to CRM structures, and if you
just have unstructured information, you have to structure it first?

-"exhaustively in terms of CRM concepts" (Page 2, section 1.2, use case no.
4), All instances of (a queried) CRM concept?

-***Nick*** means that Nick provides an appropriate section about use cases?
Or Examples?

-The next paragraph is the central point of this document (Page 2, 2nd
before 1.3, beginning with: "In the context"): the definition of "without
loss of meaning". Regarding the email Vladimir Ivanov already sent, we want
to add:
+"By virtue of this classification" Do you mean: "Using this
+"expert conversant" How do you define an expert conversant? Is a field
expert e.g. an  art historian an expert for the classification of a

-The first paragraph of 1.3: "A CRM compatible form should not implement the
quantifiers ..." If the CRM contains quantifiers, why shouldn't they be
implemented by cardinality restrictions? What do you mean by "form"? Do you
mean a "profile"?
I try this at an example from the scope note:
"Quantification: many to one, necessary, dependent (1,1:1,n) Scope note: ...
A temporal entity can have in reality only one Time-Span, but there may
exist alternative opinions about it, which we would express by assigning
multiple Time-Spans.
Related temporal entities may share a Time-Span..." coded as e.g.
E2.Temporal_Entity P4.has_timespan minimal one E52.Time-Span. Where is the

-second paragraph of 1.3: A subset of a consistent set is consistent by
definition.  Is there an implicit claim that the superset is inconsistent?
Or do you mean "proper subset" ???

Section 1.3
- The definition of single concepts that crm-compatible data structure (or
something else) must contain is problematic.
For example: Think of an address management system. You could build such a
system compliant to CRM concepts like E21.Person, E53.Place etc. and with
regard to the necessary properties and inheritance rules. There would be no
need of a E12.Production Event, so such a system will never be
crm-compliant, no matter how exact the other concepts, properties and
restriction are took into account.
Is this desirable?

-Section 1.4 first paragraph, second sentence:
+"in in"
+What are "implicit concepts"? If "concepts" are present in elements of
a data structure they are not implicit, but explicit. May be it would be
better to understand, if one can provide an example for such a concept.
The whole story about formal ontologies for automatic processing is that
everything (concepts, properties) has to be defined explicitly.
Of course, you may infer by inheritance that e.g. an instance has some
(previously implicit) properties which are now made explicit by virtues of
the reasoning step.  Nevertheless, the concepts and properties are defined

Section 1.4 / 1. Paragraph / 3. Sentence ("As long as these concepts can  be
encoded as instances of E55 Type (i.e. as terminology) ..."):
If a concept is encoded as instances of E55 Type in the sense of a term, it
has the notion of a lexical concept. As such it can not have the same
(suitable) properties as the original data item. Shouldn't we update this to
actually (in London) updated definition of E55?

Example: The term Artist (i.e. the propositional form Artist(x) in
Cristian-Emil's proposal) in a thesaurus does not have a birth date, but
instances of the subclass ARTIST of E21.Person (or whatever) of course
inherits this property if the superclass has it.

-Section 1.4 second paragraph: The first sentence could be easily
misinterpreted in a way that you have to consider at least only one
CRM-concept to build an export-compatible data structure. A reference to the
reduced CRM-compatible form defined in 1.3 should be added at this point.

-Section 1.4 third paragraph: First occurrence of the term "record". Is this
a "data record" from a database?
Or just "record" in everyday language, i.e. a written account of something.
This point to a major problem in the whole document: It is not clear whether
the terms are used as in commonsense language or whether they are used
terminologically, i.e. in  a scientific way.

-Section 1.4 5. paragraph: How does the reduction work, if we declare that a
classification must be implemented "without loss of meaning"? (relation to
Page 2, 2nd before 1.3, beginning with:
"In the context")

"Loss of meaning" can be stated only between formal systems --- if we refer
to text, "meaning" and "loss of meaning" can be argued about, but there may
be the situation that no agreement will be found.

-Section 1.5 first sentence: "all user data". How does this information
system work if "not all CRM concepts may be represented by elements of an
export-compatible data structure"? (Section 1.4, 2nd paragraph)

-Section 1.5 2. paragraph: A "partially import-compatible data structure" is
not yet defined by this document.

-Section 1.5 3. paragraph: What are "generic data"?

-Section 1.5 5. paragraph: What is a "semantic reduction"?

-Section 1.5 6. paragraph, last sentence: Do they choose on CRM basis?

-Section 1.5 figure XXX: The meaning of figure XXX is not really clear to
us. E.g. What does the data export arrow to the left side mean? The
paragraph beneath the figure claims that it shows only *some* of the data
flow patterns. It is not clear which patterns are shown an which not (and
why). If we really like to have figures in this document, there should be
one figure which shows all the data flows mentioned (export-compatible,
import-compatible, access-compatible). This figure can easily become to
complex, so that three figures, one for each defined pattern, would be

Section 1.6, For export-compatible, a.: "other than" Does this mean all
other concepts except E1 and E77?

We additionally found some questions (sent by email) that are still left
open in the V4 document. E.g.:
-"Obviously there is also an implicit research issue: How to define a
mapping that proves incompatibility. Help from the computer science
community appreciated."
-"Should we distinguish notions of  intensional/extensional meaning?
Should we introduce relationships that preserve meaning (equivalence,
-"Dear Nick,
I think only you and Patrick can answer this question: What do other
standards do about verification?"
-Some questions raised at earlier stages of the document (V2) by Prof. Görz.

As a whole there seem to be many points that need to be further clarified
and discussed so that it is not ready to be forwarded to ISO. Nevertheless I
see the benefit to have a standarized and detailed definition of
crm-compatibility inside the iso-standard.
A suggestion: Would it be possible to send the updated crm-definition with
the old compatibility part to ISO this year and send a new compatibility
part as an update of the ISO-standard next year? That would lower the
deadline pressure of the discussion and could lead to a
compatibility-definition we all agree on.

kind regards, on behalf of the authors
Bernhard Schiemann, Dipl. Ing.
Artificial Intelligence Division
Department of Computer Science
University of Erlangen-Nuremberg
Haberstr. 2, D-91058 Erlangen, Germany

Tel.:  +49-9131-85-28984
Fax :  +49-9131-85-28986
Email: schiemann at informatik.uni-erlangen.de
To verify my keys, please use gpg keyserver:

More information about the Crm-sig mailing list