Dear all,
I have no problem in this criticism. I absolutely agree that a scope note should be short and easy to understand. I tried to unify Guenther’s and Martin’s rather abstract definitions.

(As many native non-English-user I am used to the universal language of science - broken English. Subtleties and fine nuances should be avoided in the scope notes. They are usually overlooked and lost in translation.)

For most museum documentalists E55 Type it is sufficient to explain that E55 Type corresponds to controlled vocabularies and thesauri. Museum professionals are not realy interested in formal logic. The E55 Type should be given a scope note ewhich is simple and easy to understand perhaps not for 12 years old, but for the majority of our intended user group. The discussion of logic systems, deduction and reasoning can be placed in a chapter in the introduction named "CRM, logic and computer assisted reasoning".

Christian-Emil

Scope note
The E55 Type comprises terms from thesauri and controlled vocabularies used to characterise and classify instances of CRM classes. Instance of E55 Type represent concepts (universals) in contrast to instances of E41 Appellation which are used to name individuals.

E55 Type is the CRM’s interface to domain specific ontologies and thesauri. Such can be represented in the CRM as sub class hierarchies under E55 type possibly with additional properties.

(some examples)


On 21.10.2008 17:23, martin wrote:
Dear Christian-Emil,

I know the exercise is getting very tiring, but

I would follow Matthew here. Even though I agree generally with all what is 
said in
the scope note, I think the scope note itself should be very small and concise. 
It should
just say what the Type in the current paradigm is - something like: "the 
intension of a concept,
typically identified by a term, used to describe a refinement of the 
classification of an instance
of a CRM class." or so.
I would avoid the term 'subtyping' ("allows for additional refinement through
  sub-typing of the classes"), because it introduces new ambiguities of the 
same kind we have already discussed.

All other comments should go into the text in the introduction about types, 
latest from
"A type, that is, an instance of E55 Type can be interpreted in several ways. " 
on.
There we can discuss alternatives, and then state what the CRM actually models.

The reason I see not to put a class under the CRM class hierarchy, but to use 
an E55, is typically
because it does not introduce relevant relationships or is too fuzzy.

The term 'Type' in Natural History is actually a type of relationship, modelled 
in the CRM
as "taxonomic role" : "P136.1 in the taxonomic role: E55 Type" (holotype, 
lectotype etc.)

I'd suggest to arrange all this good thought in the introductory text about 
Types. Since our audience
is has often some philosophical understanding, I would rather make the duality 
you mention quite
explicit.

Matthew, how would you describe E55 Type in the scope note?

Best,

Martin

Dr Matthew Stiff wrote:
Hi Christian (and all)

I was unable to be at the Athens meeting and, frustratingly, will be in Jeddah when you meet in London (typical!). I wonder if it would be possible to post the issue that this is addressing on the list? Having read the original scope note and Christian’s amended version I am concerned that the meaning of E55 Type is, if anything, becoming more opaque. Christian is not to blame for this – The seeds of this were already there in the original scope note. Having been responsible for drafting a lot of these I am only too aware of the temptation to add text to clarify ambiguities rather than seeing if the original text could be rephrased to remove the problem. As a native English speaker I am finding some of these scope notes increasingly difficult to understand so I can only imagine how difficult it must be for non-native speakers!

I think it might be better to return to first principles and write a number of simple statements saying what E55 Type IS and IS NOT. We could then use these as the basis for producing a scope note that could be understood by an intelligent 12-year-old (well, ok, we could push this to 16-year-old).

Best wishes,

Matthew

Dr Matthew Stiff

19 Riverside Road

Oxford

OX2 0HT

(t)           +44 1865 425982

(m)         +44 7939 151510

Dear all,

In the SIG meeting at CIDOC 2008 in Athens I was asked to write a draft

for a new scope note for E55 Type and adjust the paragraphs about types

in the introduction. Yuo will find my suggestion for the scope note

below. I postpone the intro part until a decision in taken on the scope

note.

The scope note is based on the original and on Guenther's suggestion

from May. The intention has been to make the scope not more explicit on

E55 Type's function as an interface to external classification systems

and to avoid the use of the term 'meta class'. In my opinion a type in

the CRM is a term, concept or predicate. It is not equal to the set

denoted by this term. Martin pointed out in an email that there is very

little difference between the interpretation of a CRM class and this

interpretation of a type, eg 'information carrier' (CRM class) and

'wineclass' type.

I agree that any CRM class (as a concept) and and instance of E55 have

the same extensional intentional set/term duality. A difference is that

we do not have any mechanisms inside CRM (if we do not follow the

suggestion from Vladimir Ivanov) to speak about a CRM class as a whole

as we can with respect to an instance of E55. So even though 'wineglass'

  seen from a bird's view of the model is the same beast as 'information

carrier' (hypothetical sets of something), there is a difference in the

model qua a formal system.

Regards,

CHristian-Emil

----------------------------------------------------------------------

NEW TEXT E55 Scope Note

----------------------------------------------------------------------

E55

Type

Subclass of:    E28 Conceptual Object

Superclass of:  E56 Language

                 E57 Material

                 E58 Measurement Unit

Scope note:

The class E55 Type comprises concepts (universals) and hence provides an

interface to domain specific concepts external to the CRM.  In this

fashion, a connection between the CRM and a particular (external) domain

concept as a subclass of E55 Type can be established.

This hierarchical relation allows for additional refinement through

sub-typing of the classes (of the CRM) which represent important

typological distinctions but where the given user group does not

consider it necessary to give a further analysis of the classes by

extending the CRM with new sub classes. The interpretation of these

sub-types is based on the agreement of the specific groups.

A type, that is, an instance of E55 Type can be interpreted in several

ways. It can be seen as a term in a thesaurus or as predicate with a

free variable in a logical system. The instances of  the CRM classes

having a given type (e.g. through  P2 has type) at a given point in time

form a set or a class. However, this class or set is not identical to

the type.

E55 Type reflects the characteristic use of terms like "Object Type",

"Category", "Classification" etc in museum documentation. Such fields

are used for terms that declare that the object belongs to a particular

category or class of items.  It has however nothing to do with the term

`type' in Natural History (cf. E83 Type Creation) which is a E24

Physical Man-Made Thing (eg an dried insect on a needle) . But E55 Type

includes the notion of a `taxon' which are concepts.

Ideally, (external) subclasses of the class E55 Type should be organised

into thesauri, with scope notes, illustrations, etc. to clarify their

meaning.  In general, it is expected that different domains and cultural

groups will develop different thesauri in parallel.  Consistent

reasoning on the expansion of subterms used in a thesaurus is possible

insofar as it conforms to both the classes and the hierarchies of the

CRM.  E56 Language, E57 Material and E58 Measurement Unit have been

defined explicitly as elements of the E55 Type hierarchy because they

are used categorically in the CRM without reference to instances of

them, i.e. the CRM does not foresee the description of instances of

instances of them, e.g., the property instance `P45 consists of : gold'

does not refer to a particular instance of gold.


------------------------------------------------------------------------

_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig



Reply via email to