Dear all, As an attempt to clarify the problem of modelling alternatives with CRM-types --- this is the term I will use to distinguish it from other uses of "type", as e.g. in computer science --- let me start with quoting a section from the paper I submitted to the CIDOC 2008 conference. In order to avoid higher-order (logic) constructs which in my view are probably hard to comprehend for practitioners anyway, without excluding a weak form of reification completely, I suggested two ways of representation:
<quotation> ``... E55 Type has been implemented as a class which --- for the purpose of reasoning on the conceptual level --- may serve as an interface to external concepts of formal domain ontologies (or thesauri) as subclasses or as constants. In fact, at least two different representations are possible: - The usual way to attach concepts of a domain ontology to the CRM is direct subclassing, e.g., the (application domain) class Artist as a subclass of E21 Person. So, ``Vincent van Gogh'' would be an instance of Artist and inherit all properties of E21 Person. In that case to represent Artist also as a subclass of E55 Type would lead to contradictions. - Instead, a constant ``Artist'' may be used; in general, it will be a term of a domain-specific thesaurus. Such constants (``individuals'') are admitted in T-Boxes by means of the ``one-of'' OWL-DL language construct, i.e. an enumeration datatype. They correspond to classes with singleton extensions. So, we could represent ``Vincent van Gogh'' as an immediate instance of E21 Person and relate it by P2 has type to E55 Type with value ``Artist''. In this case, of course, the constants cannot have instances in turn. Both representations are not mutually exclusive; in our example the name of the class Artist (case 1) could additionally be used as a constant which is assigned as a value to E55 Type (case 2), but then it is up to the user to guarantee for semantic integrity. In the second case the intention expressed in the CRM document is supported that is shall be possible to deal with domain concepts --- such as Artist --- as objects of discourse. Which of these representations will be chosen for a particular application will depend on the intended use of the domain model.'' </quotation> What I am proposing here is to provide possibilities to argue with and about terms, i.e. use terms in reasoning in a ``de re'' and a ``de dicto'' mode. De re corresponds to the first way of representation: We introduce domain level classes as subclasses of CRM-classes. The domain level classes may have subclasses in turn as, e.g., Painter and Sculptor as subclasses of Artist; so all of our instances from, e.g., a museum data base are instances of the domain ontology which in turn is connected to CRM as a reference ontology. In Description Logic (OWL-DL), reasoning with classes (concepts) is possible - intensionally, i.e. in terms of their defining expressions (T-Box), or - extensionally, i.e. in terms of their instances (A-Box = extension, i.e. the set of instances). It is important to keep in mind that we have an ``open world'' semantics, i.e. if we have as a necessary condition for a FATHER that he is a PERSON and that Exists some CHILD, which is a PERSON, (``existential restriction''), we can represent an instance of a PERSON who claims to be a father without representing explicitly the particular CHILD --- in open world semantics ``I don't know'' is a legitimate answer to the question for a child. On the other hand, there may be two PERSONS claiming to be the father of some particular CHILD (probably a rare case in the real world...), if we do not combine the existential restriction with a cardinality restriction, i.e., that there must be exactly one father for any CHILD. De dicto corresponds to the second way of representation: We introduce a constant as the value of E55 Type. In this case, we can reason about the term itself, and not about its denotation. If we use a thesaurus where a broader term for ``Artist'' were ``Person'' and narrower terms were ``painter'', ``sculptor'', etc., we can reason in the narrower-term--broader-term thesaurus hierarchy as opposed to the class hierarchy in the domain. Formally, in both cases we have a subsumption hierarchy; in our example on the one hand a class hierarchy which contains CRM classes with integrated domain classes which have a denotation in the domain (de re), in the second case in a thesaurus hierarchy of terms which don't have instances (de dicto). As mentioned above, there may be combinations where the terms are related to domain classes by a particular property such as (an extended version of) P2 has type. The latter situation reminds me of a technique we applied in our NLP work where we have a domain ontology representing a rich domain semantics on the one hand and a hierarchical lexicon --- WordNet in our case --- on the other hand. The ``terms'' above would correspond to WordNet's ``synsets'', i.e. sets of synonymous words. As synonymy is an equivalence relation, we have a typical case of an abstraction from word to (lexical) concepts: Each word in the synset may represent the equivalence class. Then we introduced a property ``has-lexconcept'' into the ontology which relates domain concepts to the lexical concepts, i.e. words by which they are expressed. But this relation has to be maintained by the system implementors and must be handled with care: Of course, it's up to them to care for semantic integrity. We can reason within the domain class hierarchy, as well as within the lexical concept hierarchy (WordNet), but combined inferences are possible as well. In the case of subsumption inferences, e.g., given a certain (domain) class and, by virtue of lex-concept, the corresponding lexical concept(s), we could ask for its superclass and the words it is related to. Furthermore, we can stay in the WordNet hierarchy, look for the broader lexical concept (synset), and ask for the domain concept it corresponds --- if there is one --- to by virtue of the inverse relation to has-lexconcept. Best, -- Guenther On 6/9/08, Vladimir Ivanov <[email protected]> wrote: > ---------- Forwarded message ---------- > From: Vladimir Ivanov <[email protected]> > Date: 2008/6/9 > Subject: Re: [Crm-sig] About Types: ISSUE PLEASE VOTE > To: Guenther Goerz <[email protected]> > > > Dear Guenther, > > > Section 9: I don't understand it at all. Could you please explain --- > > and perhaps also the colleagues who already voted for the text as a > > whole what they understand? As a side remark, I cannot make any sense > > out of the last sentence. > > The only sense of the last sentence I've made, was its correspondence > to OWL Full language. > If one allows to treat "E55.Types" both as classes and as instances, > you may face to problems with reasoning. > > Excerpt from OWL spec. (http://www.w3.org/TR/owl-ref/): > "... However, use of the OWL Full features means that one loses some > guarantees > that OWL DL and OWL Lite can provide for reasoning systems." > > these "guarantees" are related to decidability of reasoning. > > "Inference in OWL Full is clearly undecidable as OWL Full does not > include restrictions > on the use of transitive properties which are required in order to maintain > decidability." from > (http://www.cs.man.ac.uk/~horrocks/Publications/download/2005/Horr05c.pdf > , p.2) > > As for the sect. 9 as a whole, > I think the main idea was that > "you may implement a system of user-defined types (subclasses of E55 > and properties) > at necessary (in your application) level of granularity, but it should > correspond to the CRM notion of type". > > Best regards, > Vladimir. > > > > > Best, > > -- Guenther > > > > > > On 6/4/08, martin <[email protected]> wrote: > >> Dear All, > >> > >> Following the decision in the last meeting, we have to decide via e-mail > >> vote on > >> the updated attached text about types in the CRM document. I have > >> desparately tried to > >> describe as exact as possible what the CRM does, and to avoid the > metaclass > >> question, once this is a philosophical rather than an applied question in > >> the > >> current form the CRM describes. > >> > >> Please VOTE: > >> > >> ACCEPT [ ] > >> > >> REQUEST MODIFICATION: [....] > >> > >> by June 12. > >> > >> Best, > >> > >> Martin > >> -- > >> > >> -------------------------------------------------------------- > >> Dr. Martin Doerr | Vox:+30(2810)391625 | > >> Principle Researcher | Fax:+30(2810)391638 | > >> | Email: [email protected] | > >> | > >> Center for Cultural Informatics | > >> Information Systems Laboratory | > >> Institute of Computer Science | > >> Foundation for Research and Technology - Hellas (FORTH) | > >> | > >> Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece | > >> | > >> Web-site: http://www.ics.forth.gr/isl | > >> -------------------------------------------------------------- > >> > >> > >> _______________________________________________ > >> Crm-sig mailing list > >> [email protected] > >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > >> > >> > >> > > _______________________________________________ > > Crm-sig mailing list > > [email protected] > > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig >
