[Crm-sig] Compatibility document V4
Bernhard.Schiemann at informatik.uni-erlangen.de
Mon Nov 3 10:49:31 EET 2008
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 problem?
-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" ???
- 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:
+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 explicitly.
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
-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 necessary.
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
-"Should we distinguish notions of intensional/extensional meaning?
Should we introduce relationships that preserve meaning (equivalence,
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
Fax : +49-9131-85-28986
Email: schiemann at informatik.uni-erlangen.de
To verify my keys, please use gpg keyserver:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 380 bytes
Desc: not available
Url : http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20081103/12720235/attachment.vcf
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20081103/12720235/attachment.bin
More information about the Crm-sig