ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Accommodating legacy software

To: doug@xxxxxxxxxx, "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Cc: Gian Piero Zarri <gian_piero.zarri@xxxxxxxxxxxxxxxxx>
From: Gian Piero Zarri <zarri@xxxxxxx>
Date: Wed, 12 Sep 2012 15:02:51 +0200
Message-id: <505087FB.6060307@xxxxxxx>
Dear Doug,    (01)

>>> In g, George played the role of giver, the book played the role of
>>> given, and Mary played the role of reciever.
>>>> Yes, and this is simply expressed in NKRL - an n-ary representation
>>>> language, see
>>>> http://www.springer.com/computer/ai/book/978-1-84800-077-3
>>>> - as a "predicative occurrence" (instance of a standard NKRL template)
>>>> like:
>>>> MOVE
>>>> SUBJ GEORGE_
>>>> OBJ BOOK_1
>>>> BENF MARY_
>>>> date-1: 2012-09-06-16:30
>>>> date-2:
>>> This example seems to show the reification of an instance of MOVE,
>>> and a few binary relation independently providing information about
>>> that instance.   Additional binary assertions could be made about
>>> the event (the speed of the motion, its trajectory, the form of the
>>> motion (sliding, being handed, being tossed, being posted), etc.
>>> If the reified MOVE were named, assertions could be added at a
>>> separate time from when these were stated.
>> [GPZ] Yes of course. The particular predicative occurrence shown above
> I did not consider the phrase "predicative occurrence".
>
> The meaning of this term evidently is an instance of a template, which
> has a predicate as a head.  In this case, MOVE is a predicate, not a
> type of event.    (02)


[GPZ] Yes. MOVE is a predicate that, associated with proper "functional 
roles" and "arguments of the predicate", makes up the skeleton of all 
the templates of the MOVE class. These are used to encode elementary 
events (under the form of predicative occurrences) of the "move a 
physical object or an animate entity" form, but also to represent 
"transmission of information (e.g., messages)", "transfer of knowledge 
or financial resources", "changes of states" etc.    (03)


>
>> is endowed with a "conceptual label", say "occ1" for simplicity's sake.
> This reminds me of when FORTRAN was limited to 6 character names.
> But this language seems to love 4 characters (yes, i see that CAUSE has
> five).    (04)


[GPZ] Very amusing but, unfortunately, totally false. Interested people 
should (freely) download, from 
http://www.springer.com/computer/ai/book/978-1-84800-077-3, Chapter 2 of 
the NKRL book. Even if fundamental NKRL topics like the inference 
procedures and the description of the two ontologies are described in 
other Chapters, they could at least learn something about the NKRL data 
structures. Returing now to the conceptual labels, users are completely 
free to use names of their choice, and this has no tangible consequence 
from a software point of view. A "good practice" suggests, however, to 
make use of labels of this type: "afga0022.c4". In this particular case, 
the left side of the label makes reference to the document n. 22 (a news 
story) of a corpus of news dealing with the Afghanistan war, while the 
right side indicates that the referred occurrence is the fourth built up 
during the NKRL encoding of this specific news. But, I repeat, this is 
only a pragmatic/mnemonic trick.    (05)


>
>> This allows us to "reify" this occurrence by using it in a second order
>> structure,
> What is being reified is a structure, not the "meaning" of the structure.
> Reification allows the inclusion of one structure within another without
> requiring the first to be fully stated.    (06)



[GPZ] More precisely, in a knowledge engineering context, “reification” 
concerns the possibility of creating new objects (“first class 
citizens”) out of already existing conceptual structures and to ‘say 
something’ about them without making reference to the original entities.    (07)


>
>> a "binding occurrence" of the type, e.g., (CAUSE occ1 occ2).
>> "occ2" will be now the conceptual label of another predicative
>> occurrence, for example
>> EXPERIENCE
>> SUBJ MARY_
>> OBJ (SPECIF birthday_ MARY_)
>> date-1: 2012-09-06
>> date-2:
>> and the global meaning of the binding occurrence - with its own label
>> "occ3" - will be: George gave the book to Mary because of the Mary's
>> birthday. At the difference of MARY_, an individual, "birthday_" is a
>> concept of the "standard" (binary) NKRL's ontology, specific term of
>> "reified_event" through, among other things, "anniversary_". All this is
>> more complicate to write down than to use in practice.
>>> Assumptions were made in translating "gave" to "MOVE".  The word
>>> "gave" would also cover a transfer of ownership with no movement
>>> of the book.  [Mary is reading George's book.  George says, "you like
>>> that book?  You can have it."]
>> [GPZ] Well, starting from a given date, Mary will OWN it.
> Does the MOVE predicate imply that?  My phrase did.
>
> The English word "give" also covers the cases of lending, and of
> merely transferring physical possession (e.g., George gave the book
> to Mary to put on the shelf that was to high for him to reach), returning
> something borrowed, etc.  Such cases do not imply that Mary_ will OWN
> the book.    (08)


[GPZ] I don't see the problem. In concrete applications, you normally 
don't dealt with isolated sentences/situations/events, but with sets of 
them. If your "document" (in the most general meaning of this word") 
explicitly tells us that the reason of giving the book to Mary was 
asking Mary to put this on the shelf, no OWN occurrence will obviously 
be produced. Note that, however, if the fact of "putting on the shelf" 
was not mentioned at all in the "document", and if a rule of the 
type"giving an object to someone normally implies that this last owns 
it" is present in the rule repository of the system, NKRL's inference 
engine has perfectly the right to infere that Mary owns the book. 
NKRL'rs users must be conscious that any result derived from the 
inference engine are valid only as hypotheses that depends on a) the 
rules inserted in the system; b) the "factual" information present in 
the original "document(s)".    (09)


>
>>> The slots (SUBJ, OBJ, BENF, date-1) are very generic, evidently relying
>>> upon the type of the instance (a MOVE) to give them more specific
>>> semantics. William's suggested slots (giver, given, receiver) are less
>>> generic, and better suited to the verb "give".  I would prefer using
>>> more
>>> specific relations on encoding the meaning of the statement
>>> (performedBy, providerOfMotiveForce, fromPossesser,
>>> toPossesser, primaryObjectMoving, objectOfPossessionTransfer,
>>> dateOfEvent), recognizing that if one is
>>> parsing NL, the more generic ones are necessary
>> [GPZ] The "external" name of the roles in NKRL are purely conventional,
>> you can rename them as giver, given, receiver or whatever if you want -
>> the problem being, of course, that you can use "giver" only in a
>> "giving" context.
> Then this would not be a rename.  Such predicates are specializations
> of the more general ones.  Each has a different semantics.
>
>> in NKRL, the "meaning" of the roles is supplied by
>> their practical use within the different "templates", i.e., the general
>> classes of elementary events from which predicative occurrences like
>> occ1 and occ2 are created.
> The interesting thing about the occurrence of predicates in NKRL, to the
> Ontolog community i would guess, is that beyond the requirement that such
> statements need to be possible, that they can be labeled, and thus
> referenced within other statements.    (010)


[GPZ] Yes, co-reference through the use of the conceptual labels - and 
through the names of the variables for the rules - is an essential 
mechanism for assuring the logical coherence of all the NKRL structures.    (011)

>
> I'm not sure if the meaning of roles being supplied by their practical
> use is what i expect from an ontology language.  I would prefer that
> the meaning restrict the use, not the other way around.    (012)


[GPZ] Amen. I am an "engineer", and not a "theorist".    (013)


>
>>>> BENF = BEN(e)F(iciary) role.
> Is Mary the BENF because she wants the book?   If the OBJ was something
> she didn't want, such as an instance of fish guts or a bucket that was just
> filled from the contents of an outhouse, would she still be the BENF?
>
>>>> Why always reinvent the wheel?
>>> Of course, NKRL was re-inventing the wheel, as such generic slots (and
>>> more specific ones) were in use before NKRL was invented in the mid
>>> 1990s.
>> [GPZ] You have missed my argument. My remark about "reinventing the
>> wheel" was about the fact of discovering, in September 2012, that
>> "George gave a book to Mary" can be conveniently expressed by using
>> "roles".
> I must have missed someone claiming that this was a discovery.  Such
> roles have been commonly used since at least the 1970s for expressing
> individual facts about situations (and their subtypes: processes, events,
> actions, static situations, etc.).
>
> Yes, the NKRL language adopted the common idea of slots/roles.
> However, it seems to have created a small set of generic slots.
> I have glanced at a few articles about NKRL, but they have not
> advertised a method for creating subroles.  It seems to distinguish
> predicates (from which "predicative occurrences" can be generated)
> and roles.    (014)


[GPZ] Of course, "predicates" and "roles" (functional roles) are 
disjoint categories. To build up a valid predicative occurrence you must 
have a predicate, at least a role (SUBJ is mandatory) and at least an 
argument of the predicate introduced through the role. The "arguments" 
(simple and complex) are formed using entities from the standard 
(binary) ontology of NKRL, individuals like MARY_ or concepts like book_    (015)


Regards,    (016)


G.P. Zarri    (017)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (018)

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