No 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.
The (only) problem is that this choice influences the ontology.
> > 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). 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_from_situation_to_time_measure&recursLink=%3C&hyperlinks
- 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.
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.
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.
> > 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?
> 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?
I currently do not see what extensions of my language (or KIF) would
change the problem.
> 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.
> > 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?
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).
> 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.
Philippe