SUO: RE: lifecycle_integration_schema in WebKB-2
Dear Philippe,
See comments below.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
http://www.matthew-west.org.uk
> -----Original Message-----
> From: Philippe Martin [mailto:phmartin@meganesia.sci.griffith.edu.au]
> Sent: 02 January 2004 19:03
> To: standard-upper-ontology@ieee.org
> Subject:
>
>
>
>
> Happy new year everyone,
>
> Thanks Matthew for your comments on my first try at integrating
> the EXPRESS lifecycle integration schema.
>
>
> > Hence lifecycle_integration_schema# should be the schema identifier
> > (or lis# if you want an abbreviation rather than xpres#)
>
> No problem, as soon as I come back from holidays, I'll use lis# and
> replace my file express.html by lis.html to refine the integration.
> For now, I'll just answer quickly.
>
> > > relations on relations must be allowed (at least in the taxonomy),
> > > which is not usual in most knowledge representation
> languages (KRLs).
> >
> > Just because "most" knowledge representation languages do
> not support
> > a feature does not make it good or right. Mostly it points to a
> > limitation. Usually you can work round it. If you look
> carefully you
> > will see that we used EXPRESS essentially to define our own
> language.
>
> I saw it when integrating the schema.
> Most KRLs (KIF, CGs, ...) use contexts instead of relations
> on relations,
> which seems more handy in some cases.
MW: Contexts tend to be used by languages that are themselves looking
at representing natural language - not surprisingly since in language
a lot of stuff is unsaid (i.e. in the context) - this is what makes
language efficient, but is a nightmare for computers. Contexts are of
course just a particular way of putting relations on relations.
MW: KIF does not have context as a concept.
MW: The lifecycle_integration_schema is not language based. In fact
one of the design principles is to make the context explicit as facts.
Hence (amongst other things) relations on relations.
MW: If we look at how you can implement relations on relations there
are basically 2 approaches based on how you identify the relation:
1. Use the relation as its own identity: i.e. when you want to refer
to a relation as an object in a relation, you put the whole relation
in there - the relation is its own identity. This approach is typical
in language based approaches, and is what KIF does.
2. Reify the relation: i.e. create an identifier that stands for it.
Now when you want to refer to the relation you can use the reified
object to denote the relation in another relation. This is the approach
you need to take in structured data based environments, and is what we
will need to do if we are to establish a register.
Note: There is no semantic difference between these approaches.
> The (only) problem is that this choice influences the ontology.
MW: Why? The ontology is the ontology. If you are going to do something
that "influences" it (i.e. changes it) then you are simply not able to
support the ontology, and we need to start to look at why.
>
>
> > > If this option is selected, since the relationships are refering
> > > to particular kinds of situations (i.e. of states or processes),
> >
> > This is not true. This is a 4D ontology. There are (at least)
> > 3 types of relationship:
> > 1. ...
> > 2. relationships between two classes, these are of course eternal
> > and generally denote rules that apply universally. Specialisation
> > is an example of such a relationship. I imagine that you would
> > hardly consider that "centrifugal pump" is a specialisation of
> > "pump" as a situation.
>
> Actually, I do. If lis#specialisation is not a relation type but a
> concept type, I'd prefer it to represent a process (the act of
> specializing).
MW: What you are now doing is taking an ontology developed using one
paradigm and translating it into what I presume is your preferred
paradigm. This does not preserve the intended semantics of the
original ontology. You can use it to suck concepts out of other
ontologies and have an "equivalent" representation in your own
paradigm, but you do not preserve the original paradigm.
MW: Let me explore some specific issues here. You seem to assume
that a specialisation is something that is human created. Not so,
at least in the 4D paradigm I am using. Classes/sets and tuples
are all universal objects, i.e. they exist for all time and are
unchanging in time. So you couldn't possibly create them. You
might discover, record, use them, but that is rather different
(and is already dealt with elsewhere in the activity part of
the ontology).
> Such a representation has several advantages:
> - it permits to re-use the usual relations associated to processes
> or more generally situations: point_in_time, agent, result,
> instrument, pre_condition, preceding_state, ... For details, see
> http://www.webkb.org/bin/categSearch.cgi?categ=pm%23relation_f
rom_situation_to_time_measure&recursLink=%3C&hyperlinks
MW: I already have an ontology of processes and it already has some
of these things (though note in particular that the view of time
is likely to be different - and again must no be contaminated).
> - lis#specialisation may be inserted as a subtype of wn#specialization
> which is direct subtype of wn#change_of_state and hence an indirect
> subtype of wn#human_action and pm#process (wn#cognitive_process
> would also be an adequate indirect supertype but this is not yet
> the case in WordNet and I have not yet set this link). Such a
> classification is interesting for knowledge sharing (directly, via
> a shared ontology, and indirectly as indicated in the previous
> paragraph because it eases easing graph matching). This is not the
> case if lis#specialisation is represented as a particular
> concept type
> of abstract object.
MW: But there is no change in state - see above.
>
> This is my main problem in the integration of the EXPRESS lifecycle
> integration schema (the other problems are minor ones and will be
> solved). Any indication to mix the two approach is welcome.
MW: The answer is simple, relationships need to be referenceable
objects.
>
> My notion of "situation" is the same as John Sowa's (at least in his
> writings of 1992 and around). A situation "involves" objects and
> "happens" in a real/imaginary world. In other words, the
> representation
> of a situation quantifies objects (of type pm#entity or pm#situation)
> and possibly connects them by relations, and it can have an associated
> relation of type pm#point_in_time or pm#duration. A concept node of
> type pm#situation may also be connected by a relation of type pm#descr
> to a concept node of type pm#description which may be
> connected to other
> concept nodes of type pm#description by rhetorical or argumentation
> relations.
MW: The concept of situation does not exist in (and is not relevant to)
the lis. It may be relevant to your view of the world.
>
>
> > > they have to be represented as subtypes of pm#situation and
> > > connected to their closest matches in the ontology of WebKB-2
> >
> > Why do they have to be? It seems to me that the most sensible
> > thing would be to add something in addition at the level of
> > situation.
>
> I think my previous paragraphs answer this. If not, could you give a
> name (or further details) for the new needed concept type?
MW: I would call it abstract_object or universal, and I would have
tuples and sets (at least) as subtypes, and relations as specialisation
of sets. All of these would be referenceable objects.
>
>
> > I can most inform you most assuredly that they are subtypes of
> > abstract object, and that to make them into something else (and in
> > particular into situations) is to make a fundamental change.
>
> Is that still true in light of the above?
MW: Absolutely.
> I currently do not see what extensions of my language (or KIF) would
> change the problem.
MW: See above.
>
>
> > 1. mapping of xprs#thing. You have said that this is equivalent to
> > dolce#entity. This is rather unlikely. ...
>
> I wasn't sure given the documentation I accessed.
> I'll try to fix those 3D/4D integration problems according to your
> further answers.
MW: It is alarming how different various conceptualisations of the world
are. you might almost think they related to different realities.
>
>
> > > I hope that these membership connections are not actually refering
> > > to instance links because then some types of
> relationships would also
> > > be meta-classes of relationships. Hence, in Option 1,
> instance links
> > > between relation types would have to be allowed.
> >
> > Well that is probably the case. classes of relationship generally
> > have relationships as members. There can also be class of class of
> > relationship that have class of relationship as members.
>
> I am still confused about your use of the word "member". Do you
> refer to the instance relation or the membership to a collection?
MW: Well I don't know what you mean precisely by the instance
relation or collection. I reserve membership for membership of a set
(remember relations are sets). The main alternative relation is
mereological composition (whole-part) which is between individuals.
> And I still have problems to imagine a relation type having for
> instance another relarion type. (No problem if the relationships
> are represented as concept types).
MW: Well lets take a practical example: some relations are transitive,
and transitive is itself a relations (transitive from-to).
MW: One way out of this is if you can handle pure tuples as
(referenceable)objects. Then everything else can be expressed in terms
of relationships between classes and tuples.
>
>
> > It would probably be worth talking about that aspect of
> > our work with how it relates to your meta-concepts as a next step.
>
> Indeed. May be offline if this is not the forum to do this.
MW: Well we are well on topic here. The Lattice of Theories is a key
proposal in the work of the SUO WG and we are discussing problems
that will affect incorporating any ontology into it. So we should be
OK here.
MW: Could you start by elaborating what the key language constructs
you have in WebKB-2 are?
>
>
> Philippe
>
>