On Thu, October 4, 2012 11:53, Gian Piero Zarri wrote:
> On 04/10/2012 16:24, doug foxvog wrote:
>> On Thu, October 4, 2012 07:00, Gian Piero Zarri wrote: (01)
>>> ... solutions in the "qua-individuals" style like
>>> those proposed by Masolo and Cie. are not only inelegant but, mainly,
>>> actually impracticable because they lead to a quick proliferation of
>>> individuals: "JOHNquaHarvard-student" becomes, in fact, an instance of
>>> a concept like "student". And "student", moreover,
>>> is a "transient property" that cannot be instantiated. (02)
>> If you only allow the instantiation of rigid classes, then, by
>> definition, "student" cannot be instantiated.
>> One can instantiate an instance of "person" --
>> or whatever the nearest subsuming rigid class is -- and
>> associate the role "student" with it in the appropriate timeframe. (03)
>> However, Masolo & Cie do allow the instantiation of non-rigid classes,
>> such as "student". Since they DO it, they CAN do it in their system. (04)
> This is a sort of casuistry. Apart from the logical mistake of declaring
> instances of "student" or "customer", (05)
It depends upon the context in which you make such a declaration.
This would be a logical mistake if such a declaration was made in a
timeless context. (06)
However, many databases (and therefore knowledge bases built from them)
are correct only for a specific period of time. If throughout that period,
someone was a student, i do not see a logical fallacy in declaring them
an instance of "student" IN THAT CONTEXT. (07)
Having "customer" as a class, on the other hand, is rather meaningless.
This does not mean that it would be a logical mistake in a temporal context. (08)
Almost everyone over a certain age in a non-rural or hunter-gatherer
society has made purchases as have most corporations and
organizations of various other types. This is not an interesting
fact to record in a knowledge base about a specific person or organization.
What is useful to store is a relationship holding between an agent
and a purchase (or rental) event. (09)
Somewhat less useful is storing a cumulative list of the types and amounts
of things an agent has purchased or rented. Even less useful would be
recording that a given agent at some time was a customer of a given
firm. For marketing purposes, it is useful to know the kinds of things
an agent purchased, from whom or what kinds of vendors, and other
items or summaries of purchase history. (010)
In such cases, it might be useful to create subclasses of the overly
generic "customer", such as AppleProductsPurchaser, CitgoCustomer,
RomanceNovelPurchaser, etc. This could especially be the case
for a system that can not handle meta-classes, and has instances of
AppleProducts or RomanceNovels to sell, complicating the use of a
predicate to make assertions like: X purchasesType RomanceNovel
if the third element is required to be an individual. (011)
> can you imagine a PRACTICAL system
> of reasonable dimensions where you are continuously obliged to create
> new individuals for specifying all the possible everyday behaviours of
> John (and of all the others)? (012)
No. Even envisioning a practical system to record all the possible every-
day behaviours of a large group of people, i find hard to imagine. (013)
It sounds quite Big Brotherish. (014)
However, a University internal knowledge base, which has populated
the following subclasses of Person:
Student
UndergraduateStudent
Freshperson
Sophomore
Junior
Senior
ExtendedUndergrad
GraduateStudent
MastersStudent
PhDStudent
ABDStudent
Teacher
TA
Instructor
Professor
FullProfessor
AssociateProfessor
AssistantProfessor
GraduateStudent (015)
and has rules on the knowledge base that causes periodic
targeted notices to go out to members of different classes,
could be very practical. (016)
-- doug foxvog (017)
> The management of individuals is
> particularly tricky and costly in concrete KBs. (018)
> Regards, (019)
> G.P. Zarri (020)
_________________________________________________________________
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 (021)
|