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 scope.
Out of time now! Stephen Stead Tel +44 20 8668 3075 Mob +44 7802 755 013 E-mail [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bernhard Schiemann Sent: 03 November 2008 08:50 To: [email protected] 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 "Compatibility" 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 classification"? +"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 painting? -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" ??? 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 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 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 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 community appreciated." -"Should we distinguish notions of intensional/extensional meaning? Should we introduce relationships that preserve meaning (equivalence, subsumtion)?" -"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 -- ************************************************************* 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: [email protected] http://www8.informatik.uni-erlangen.de/inf8/en/schiemann.html To verify my keys, please use gpg keyserver: pgp.mit.edu *************************************************************
