SUO: Lifecycle Integration Schema in WebKB
Dear Philippe,
Sorry to take so long to look at your interesting work on the
lifecycle_integration_schema that you have set up here
http://meganesia.int.gu.edu.au/~phmartin/WebKB/kb/express.html.
I will start by taking your preamble and commenting on it.
PM: Following are representations (in the FT and FCG notations)
of most categories of the EXPRESS lifecycle integration schema
(or Standard ISO 15926-2:2003). The string "xprs" is used as an
identifier for this schema, and hence "xprs#" is used to prefix
categories from this schema.
MW: There seems to be some confusion here. EXPRESS is the name
of a language in which data models are written. There are
literally hundreds of data models written in EXPRESS, and they
are not generally compatible with each other. The namespace is
only unique within a schema (such as the lifecycle_integration_
schema) not within the data modelling language. Hence
lifecycle_integration_schema# should be the schema identifier
(or lis# if you want an abbreviation) rather than xpres#.
PM: A choice has to be made between the following two options
for the represention of the EXPRESS relationships.
PM: 1. They are represented via binary relation types. This is
the simplest solution but, since about twenty of the EXPRESS
relationships connect to other relationships, relations on
relations must be allowed (at least in the taxonomy), which is
not usual in most knowledge representation languages (KRLs).
MW: 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.
PM: In EXPRESS, each relationship also has two "attributes" which
explicit the role of each end of the relationship; these
attributes may be represented via relations on relations too,
or to ease knowledge entering/readability (in most KRLs), may
be left implicit (which is what is done below, e.g see
xprs#relationship).
MW: Yes, these attributes are how many traditional models
represent relationships. You will note that we did not use
this feature to represent relationships. This is precisely
because relationships are objects that you might want to
refer to.
PM: 2. The EXPRESS relationships are represented via concept
types, and their attributes via binary relation types. This
option is more general/scalable and seems more appropriate
to the intent of EXPRESS and its use for knowledge representation.
MW: EXPRESS has no such intent, but the lifecycle_integration_schema
does. Entity types in EXPRESS are a match for your concept types,
and seem to have the same sort of capability.
PM: If this option is selected, since the relationships are refering
to particular kinds of situations (i.e. of states or processes),
MW: This is not true. This is a 4D ontology. There are (at least)
3 types of relationship:
1. A relationship between one possible_individual and another.
The possible_individuals will most probably be states (temporal
parts) of other possible_individuals, and the relationship will
say something true about those states. This is closest to your
description of situation, but this concept seems to match most
closely with our concept of possible_individual - some piece of
space-time (though this is only true if situations include
activities/processes/events).
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.
3. Characterising relationships. These are generally relationships
between classes and possible_individual - most often classification.
Again, hardly situations.
PM: they have to be represented as subtypes of pm#situation and
connected to their closest matches in the ontology of WebKB-2
MW: 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.
PM: (most often WordNet categories that are subtypes of pm#situation).
However, this means that xprs#relationship,
xprs#class_of_relationship and xprs#class_of_class_of_relationship
(and their subtypes) can no longer be subtype of respectively
xprs#abstract_object,
MW: 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 to the
intent of the lifecycle_integration_schema. If you have to do this
to enable integration, then I am afraid that you have fallen short
of what I think needs to be achieved.
PM: xprs#class_of_abstract_object and
xprs#class_of_class, but have to be subtype of xprs#activity
(only in the first representation option, the notion of
relationships as abstract objects makes sense).
MW: Why?
PM: Thus, three subtype
links have to be broken. Another problem is that in EXPRESS some
relationship attributes have the same identifiers as some other
types. Since in many languages (e.g. KIF, FT, FCG and RDF), the
namespace of relation types is the same as other types, some
identifiers have to be changed.
MW: The conventional way of doing this would be to refer the the
attributes as EntityType.Attribute. However, in the language we
have defined in EXPRESS we take the relationship as representing
the role (relationship name) and domain (entity type related to).
PM: Option 1 has currently been selected, but Option 2 will be
used if I am asked to. Types for relations on relations have been
included but isolated within "if (with_relations_on_relations) {...}"
blocks to permit their exclusion by setting the variable
with_relations_on_relations to 0.
MW: Neither option as currently stated would be acceptable. I
think we need ot look a bit more fundamentally at the sorts of
things that your language can represent, and perhaps consider some
extensions to it.
PM: with_relations_on_relations := 1; //this is not a predefined
variable in WebKB-2
if ($with_relations_on_relations)
{ allow types of relations on relations; //this is a command in WebKB-2
//(I have added it to permit Option 1)
}
MW: This looks like an example of a possible extension, but frankly
I have little idea of how this might work.
PM: Commands/representations are displayed in the courier font.
They are enclosed within the XHTML marks <KR> and </KR> to permit
WebKB-2 to distinguish them from regular text. They have already been
parsed/loaded by WebKB-2; thus, you can click on the hyperlinked
"xprs#..." category identifiers (e.g. xprs#thing) in order to browse
the EXPRESS ontology (note: for certain types, e.g. xprs#thing, a GET
parameter given in the hyperlinks restricts the depth of the displayed
subtypes).
MW: I have just looked at a couple of the entity types and how you seem
to have mapped them. A few comments:
1. mapping of xprs#thing. You have said that this is equivalent to
dolce#entity. This is rather unlikely. The lifecycle_integration_schema
is a 4D ontology and DOLCE is a 3D ontology. They will therefore have
significant variance in the objects they represent. Specifically, a 4D
ontology does not include any endurants (there are no endurants that
are instances of xprs#thing). A similar situation will arise with
classes of physical object, in the lifecycle_integration_schema their
members will be spatio-temporal extents, not endurants, and since the
memberships are different, so are the classes. I imagine that Nicola
would want to say something similar about his class of physical object
not having continuants as members.
2. With possible_individual you have DOLCE's physical_endurant as a
subtype. This is not possible. Endurants are things that pass through
time. Possible_individuals are pieces of space time and do not pass
through it. Therefore these are mutually exclusive concepts.
PM: In the documentation of EXPRESS, some membership connections are
often defined to (unfortunately only informally) via sentences such
as "A <class_of_individual> is a class whose members are instances of
<possible_individual>" and "A <class_of_class> is a <class> whose
members are instances of <class>". Although the used names (e.g.
"class_of_class") suggest that such membership connections are instance
links, the used sentences suggest this is not the case and are quite
confusing; what is the connection between class_of_class and class ?
MW: One of the problems with the EXPRESS (or indeed any
entity-relationsip language) is that you cannot directly state
relationships between entity types (the attributes are really
relationship types). So there is no way to formally say that
say possible_individual is a member of class_of_individual. In our
model this is not particularly important, because what we are really
doing is setting up the containers for classes of individual, such
as pump, so that they can be used to classify possible individuals,
such as my_pump using a classification relationship.
MW: Until I get further explanations, each of these connections is
represented via the (quite fuzzy) membership link of WordNet
(abbreviation: 'm'; or its inverse link: 'M'); "xprs#a m xprs#b" can
be read: "any instance of xprs#a may have for member 1 or more instances
of xprs#b" (FT permits the user to give a more precise cardinality but
[0..*] is the default).
MW: That sounds like a good interpretation.
PM: 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.
MW: 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.
PM: More generally, there
would be many meta-classes that should rather be represented as
first-order classes for knowledge entering/inferencing/re-use purposes,
e.g. xprs#property.
MW: I don't know what you mean here.
PM: On the other hand, with the current solution and in Option 1,
memberOf links must be allowed between relation types,
MW: That is true.
PM: which is not
satisfactory either.
MW: I don't see why this should be unsatisfactory.
MW: Well thanks for the work you have done on this, the results are
certainly interesting and I think highlight some of the problems one
can expect when trying to bring together work from different cultures.
MW: One of the things which I think characterises our work is that we
have looked hard at what we really need to represent the world
accurately, and I know we have come to some different conclusions to
many people. It would probably be worth talking about that aspect of
our work with how it relates to your meta-concepts as a next step.
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