Issue 351: Modelling Principles

Starting Date: 
2017-10-09
Working Group: 
4
Status: 
Open
Background: 

On 39th CIDOC CRM-SIG meeting,  Martin made a presentaion about. “What do we describe and why” and then  presented a text about methodology. The crm-sig reviewed and  accepted as a draft document. It is decided to put this document in googledocs for further reading, adding notes and comments. Also it is decided to put the text on the site in an issue format. Homework is assigned to  Christian Emil, Thanasis Velios, Marta Acierno, Achille, Alex Siedlecki and Steve to further elaborate this document on googledocs https://docs.google.com/document/d/1RKJaD71idCcKKaTEdjw_dpPU5m1i13H3tb91...

Crete, October 2017

 

 

Posted by Richard   on 19/10/2017

Martin,

I have now had chance to read this document.  I agree that, once finalised, it will become a useful guide to the modelling approach adopted by the CRM SIG.  Would it be possible for us to have a summary of the conclusions that were reached when it was discussed at the recent SIG meeting?

At 66 pages, the document is stretching the meaning of "short" (despite our commitment to maintaining independence from scale - this is a pretty large dwarf!).

It lacks a 'road map' which tells the reader how to go about getting value from it, assuming they know little or nothing about this subject when they start reading.  (Come to that, do we have a clear idea of the background knowledge and intentions of the typical/target reader?  If so, these should maybe be stated.)

The general introduction, in particular, is very dense and theoretical, and will probably cause most readers to give up before they even get to the meat of the document.  If this introduction is to remain, I suggest that it is included as an appendix.  I would also place the glossary at the end, since it interrupts the flow of the text.  (Where glossary terms appear in the text, they could have a pop-up containing their definition: in that way, they would actually be useful.)  Instead of the General introduction, I would include a short outline of the main structure of the document: process model, engineering principles, and conceptual modelling checklist.  You could briefly explain that the CRM has a particular modelling approach (and hence the need for this document), without going into detail.
I suggest that live cross-reference links to specific sections of the published CRM would help to ground the text, and would give these modelling ideas a concrete context.  This might also be an effective way of giving examples in the modelling principles section: some of the examples provided are currently too cryptic to be helpful.

Current Proposal: 

Posted by George on 1/12/2017

<PROPOSAL> <HW>

 
FYI, we have gone up a version of CRM Principles document to v.0.1.3. New text includes distinction between an ontology and a data structure. Find the new link below.
 

 

Posted by Richard  on 14/12/2017

<COMMENT>

George,

A quick look at the updated version suggests that it is substantially the same in its overall organisation.  Please see my comments to the list dated 19 October: I would appreciate a response to these.

posted by Richard on 4/1/2018

<COMMENT> <QUESTION>

On 14/12/2017 21:48, Martin Doerr wrote:
>
> This statement "some of the examples provided are currently too cryptic to be helpful." is too general to be helpful ...please tell us which ones
As a general point I don't understand why there are two 'Eg' sections for each principle.  Some have a screen icon by the first and a mouse icon by the second; others have '+' by the first and '-' by the second. Is it that you would like there to be two examples for each principle, or do they play different roles?  (In some, e.g. 1.2, there are two points in the first Eg and none in the second, suggesting they serve different purposes.)

Specifics:

    2.1 TADIRAH "Research Object" needs a note explaining (presumably) that the research intention has no impact on an object being a member of the "object" class
    6.4 Getty’s ‘Object ID’, the EAD - what do these demonstrate as regards mandatory/optional properties?
    7.1 both examples here are too cryptic: please explain what they show/what should be done with them
    7.2 is the first part of the second Eg making a different point to the first Eg? If so, it's not clear what it is. Second part of second Eg also cryptic
    7.3 examples are unexplained, though I get the general idea. The re-appearance of "Research Object" (TADIRAH) also raises the question whether 7.3 is different in substance from 2.1
    7.4 "hamlet - village" looks like a completion of the first Eg; it's not clear what we're advising to do about "ship - boat"
    8.1 isn't the second Eg the conclusion of the first one?
    8.2 the purpose of the second set of Egs isn't clear

posted by  Phil Carlisle on 4/1/2018

<QUESTION>

Hi Richard,

I agree the Examples need to be clearer especially those using symbols.

I took the ‘+’ and ‘-‘ to mean that one example was a good/positive example whereas the other was an example of what you shouldn’t do (bad/negative).

Are the symbols meant to do the same? If so can we standardize or provide a legend to clarify what is intended? Even include an annotated example of a principle perhaps.

 

 

posted by  Phil Carlisle on 4/1/2018

<COMMENT>

I’ve just cut and pasted the ‘computer’ and ‘mouse’ symbols from example 7.2 into a blank word document and they come back with a ‘smiley face’ and ‘sad face’ symbol so I think they are the same as the ‘+’ and ‘-‘ of the other examples.

posted by Marta Acierno on 6/1/2018

<HW>

I hope this mail finds you well. You may find attached the revision of the 'Modelling Principles' text. Considering my ‘entry level’, I have preferred not to work directly on the shared file, but if you prefer I can transfer my comments on it. Please feel free to disregard all the suggestions you should consider inappropriate or too naïf.

Coming to the next sig meeting, unfortunately, although both very interested, neither Donatella nor I will be able to participate. Donatella is too busy with the beginning of the university course and regarding me, my daughter will undergo a little surgery in the same days. In any case, we will participate for sure on May.

Posted by Christian Emil on 14/1/2018

<COMMENT>

Dear all,

I have read the document before reading your comments. I have many (minor) comments to the text. I am not quite sure how the group intend to proceed with the revision of the documents You will  find my comments below.  It is important that the document is read by honest persons with a introductory or medium level of knowledge.

Best,

Christian-Emil

The document needs proof reading; I assume this can be done later. We need a common term for the “original CRM”. In the document one uses CRM, CIDOC CRM, CRM Basic, CRMbasic, basic CRM. In the definition of CRM the term CRMbase is used.

The general introduction is not always easy to understand. I agree with Marta's  comments.  It is important that the text easy to read and understand. For example, split up the long sentences and assume you should explain the content to your old aunt in a phone call.

Page 11-12 Definition of empirical source material there are four bullet points. Are the two last ones subordinated case (2)?

Phase B

Each step  1 -9  will benefit from a single, good example illustrating/giving intuition to the reader

Phase C

1: Implement or express? An implementation can be considered to be a model of the ontology expressed in say FOL.

2. All classes and properties correspond to atomic predicates and a textual description is needed for each. The FOL expressions in CRM are actually examples of 1. Second order logic will rarely be needed.

Mapping

Mapping is very different from the phase A, B and C.  The phases are about ontology construction in general. The mapping is presented in the introduction to the chapter as mapping to CRM. The text in the mapping section is apparently about mapping between models in general. The section is long and detailed and should be a separate chapter. Mapping between ontologies/models is also found in logic/model theory and in algebra/category theory (functors).  For example between a model expressed in FOL and a RDF implementation there is a mapping/implementation function. One may consider to add a few sentences about the fact that mapping also is a theoretical topic with a long tradition in mathematics and logic.

Glossary

The acronyms e.g. KR should be added.

Principles:

The form used to describe each principle is fine, but ambitious.In the document the first principles are best described. The last ones are brief and only partially filled in. For each principle there is a a field for examples of good practice  or positive comments and (+ or smiley) and a field for not so good practice. Standardize the use of icon/+ and – signs. For some principles the + field describes what one should not do and not what one should do e.g. 1.2,  3.4.

Below are the short comments I wrote when reading the text. I hope they may be useful

1.1

Here the slogan is “Models should be useful”. The negative example is FRBRoo. One may conclude that FRBRoo is not useful. Consider another example or reformulate.

1.4 In the current society ‘sex’ (gender) is not a good example. Is the second example good or bad?  The negative example needs an example, but should perhaps

2.1

Most people don’t know the DARIAH/NEDIMAH typology of DH. Even is one knows about TADIRAH it is not so clear why it is a bad concept.

2.2

The negative example is about making particulars into classes or concepts. Would person be a better example? Many skilled and well educated persons fall into the trap and it takes some effort to explain to them that a person or a hammer is not a concept.

2.3

A negative example could have been the multiple  identified by we had in CRM

2.4

Slogan and negative example are missing.

3.1

No slogan.

The positive field: Explain/describe  the difference between the two “mothers”. What is a psychological concept in contrast to other concepts? Would it be possible to have a type ‘murder’ and how should it be linked to the operational description with activity and death.  A profession is usually expressed by the use of type. 

Negative example is missing.

3.2 (type on the text 3.1) 

The second example need an explanation and is negative and could have been placed in the negative field.

3.3

The positive field: What is the grammatical subject in the first sentence

3.4

The positive field: An example of what we don’t do, not what we do

4 Open world

The introduction at page 42 should open with a definition of the principle of open world assumption. The core of the principle is that lack of knowledge does not imply falsity. If a marriage is not register of marriage in, say, in Sweden, one cannot conclude that a visiting German couple is not married.  In everyday life the open world assumption neglected or considered false. (In constructive mathematics & logic one fins a similar principle, on has to construct a method to find a given construct. Ad absurdum proofs over infinite sets are not accepted.)

The text in 6.1 is clearer. Consider a revision and use the text in 6.1

4.1 

The problem description is very good.

In argument: The ‘next superclass’ is unclear. ‘abstract superclasses’ may be needed as placeholders for properties.

The gender/sex example is not a good example today. The negative example: Many (well educated) people outside Europe don’t know what Europeana is and even among those knowing few know the EDM.

4.2

is similar to 5.4

4.3 

How does this principle differ from a similar principle for classes and form the open world assumption in general?  What is “a closed world of properties”?

5.1 

Positive examples: first example, use full sentence, second example – The movie Rashomon is not known to everybody and thus gives little intuition.

The negative example needs at least a full sentence and a hint to why it is negative.

5.2

In the last senetnec of the argument field ‘ not particular interpretation of how those states of affairs came about’  may  contradict the title of the principle “Do not model conclusions before and without  their reasons”

Positive field: Explain very briefly (by footnote) what Oetzi is.

Negative field, typo: ‘starts are bad’ should be ‘states are bad’

5.3

Positive field:  Contains what you should not di (never define a class as a complement).

5.3  typo in the title ‘domains and range or properties’ should be ‘domains and range of properties’?

In the text one alters between ‘relation’ and ‘property’. Does the two terms denote the same?

Argument: A principle of conservative extension could be added to the document

The negative: add text and make the example clearer. This is very CRM specific

6.1

This is a well explained principle. It the definition of the open world assumption and parts of the text can be used in the intro of 4.

6.2

Especially in the case of contradictory information, the provenance of the information is obligatory.  Add a sentence about that.

The statement in the square brackets at the end of the argument: “Contradiction is to be supported at the level of the knowledge base, not the model” should  be made more prominent, peraps be made into a separate text or principle. A KB with contradictions is not a valid model for the theory created by the conceptual model.

6.3

Is  just a sketch and need elaboration

6.4

The principle is important to avoid misunderstandings that one needs to “implement” as described in the model.  However, the principle address several issues.

1)      An ontology does not describe the implementation level, e.g. the problem of implementing properties of properties in RDF.

2)       

3)      One don’t need to provide (fill in)  all the information indicated by the classes and proeprties of CRM. That this is necessary is a frequent misunderstanding. Should be strongly emphasized

4)       

The positive example need some more text.

The negative example: Add the misunderstanding mentioned above. Why are Object ID and EAD bad. EAD is not an ontology. it is a data format (not very good though)

7

Objectivity is  hard.

7.1  Is transaction, acquisition, transfer more neutral than bying, selling, delivering, receiving? If so, please explain. Second negative example is not very relevant for view neutral.

7.2 Argument: maybe the last sentence can be deleted. A (objective/subjective) view has to be explained and the reasons for the view has to be clear.

7.3

Positive examples?, reasons for stating the for examples as bad practice (may be considered subjective without),

7.4

Size/scale is ok. This could perhaps be generalized and extended to other characteri8stica?

8  The difference/separation of words in ordinary language and name of classes is very important, so the proposed 8.3 is important. Perhaps one should write the scope note before finding a name for a class or a property?

A very frequent case is a place name which may denote an organization place, physical structure, spatiotemporal entity.

The entire chapter 8 could be extended and get a more prominent place in the beginning of the document.

8.1 is good

8.2  Do we have an example of a binary relation (all relations can  in principle be reduced to binary relations as said in the beginning of the document)

Meetings discussed: