ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Frames vs Logic again

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Patrick Cassidy <pcassidy@xxxxxxxxxxxxxxxx>
Date: Sat, 21 Feb 2004 11:58:25 -0500
Message-id: <40378E31.7050700@xxxxxxxxxxxxxxxx>
Yes, hasName and several other concepts that neither add to nor detract
from the logical content were added to take advantage of the visual
representation capabilities of Protege.  If they bother anyone, they
can be sequestered in a separate module and left out of versions
that don't get imported into Protege.
    It is also possible in Protege to create windows with lists
of propositions where a given concept is in position 2 or 3 or whatever,
just as the SUMO browser and Sevcenko's browser have done.  But at
this point I haven't implemented that, since that is already covered
by the other browsers.  It is not a built-in function in Protege.
To cover that issue, I have only added a few inverse relations
thus far for those cases where the presence of a
concept as argument 2 in the SUMO relation can be of significance in
understanding a concept.  If it turns out that viewing relations with
classes as argument 2 is of more general interest, I can create
a separate pane for the Class window that displays such relations.    (01)

     Pat
================    (02)

Adam Pease wrote:    (03)

> Pat,
>   I noticed in your file of suggested additions the following:
> 
> --------------------------
> (instance hasName BinaryRelation)
> (domain hasName 1 Entity)
> (domain hasName 2 SymbolicString)
> (inverse hasName names)
> (documentation hasName "hasName relates an instance of an entity to a 
> string of linguistic characters used to reference the entity in 
> linguistic communication.  This is the inverse of the SUMO relation 
> 'names', added to allow more flexible representation in Protege.  The 
> hasName relation is not a necessary relation since not every entity is 
> named by a SymbolicString and not every SymbolicString is the label for 
> an entity.")
> ----------------------------
> 
> This is entirely redundant with the existing SUMO relation 'names'.  The 
> only reason one would want such a definition, is, as you note, to 
> overcome the limitations of a frame system.  A frame system is oriented 
> to inspection and reasoning on the first argument, so if one looks at 
> the frame for 'SymbolicString' one won't see the slot 'names'.  It will 
> only be visible when one is looking at the frame for 'Entity'.
> 
> If you feel the need for this inverse of 'names' a case could be made 
> that every binary relation must also have an inverse, thus doubling 
> (uneccessarily) the number of relations.  Of course, this also doesn't 
> solve the problem that all ternary and higher order relations (of which 
> there are a number in SUMO) will still be invisible in Protege or any 
> other frame system.
> 
> This is a good example of why Protege is a bad choice for a formal 
> ontology expressed in logic.
> 
> Adam
> 
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Subscribe/Unsubscribe/Config: 
> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/ To Post: 
> mailto:ontolog-forum@xxxxxxxxxxxxxxxx
> 
>     (04)

-- 
=============================================
Patrick Cassidy    (05)

MICRA, Inc.                      || (908) 561-3416
735 Belvidere Ave.               || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054        || (908) 668-5904 (fax)    (06)

internet:   cassidy@xxxxxxxxx
=============================================    (07)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config: 
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (08)

<Prev in Thread] Current Thread [Next in Thread>