On Fri, October 5, 2012 16:30, Gian Piero Zarri wrote:
> Dear John, (01)
> You are missing the central point of the discussion with Doug Foxvog,
> which concerned the theoretical and practical opportunity of adopting
> solutions in the "qua-individuals" style for getting rid of the problems
> concerning a sound definition and representation of the notion of role.
> And, in spite of Doug's objections, I maintain that endorsing a wild
> proliferation of individuals sine necessitate does not represent a
> correct methodological approach to the problem. (02)
You seem to have misunderstood me. I was not at all suggesting
proliferating "qua-individuals". Quite the contrary. (03)
> On the other hand, I am
> not interested in Facebook or in extracting knowledge from natural
> language but, mainly, in high-level inferencing starting from complex
> conceptual representations. I can reassure you: in the SQL version of
> NKRL, there are really no problems to store and manage all the required
> individuals - i.e., instances of concepts, those of course that can
> admit direct instances, certainly not "student" or "customer". (04)
There is a big difference in storing data for some application (e.g.,
a personnel office maintaining information about people at a university)
and scarfing information from the web so that it can be used for
unintended purposes. In the first case, the context is limited, so
statements may be maintained that are only true in that specific
context. In such cases, having anti-rigid classes as subclasses
of rigid classes is no problem. (05)
For a system accepting data from billions of specific contexts,
that is trying to store them in a way that every statement is
timelessly true, having instances of anti-rigid classes is problematic.
One solution would be to attach the statements to temporal contexts,
so that instead of storing: (Joe instanceOf Student) -- which can
not be timelessly true, it stores
((that (Joe instanceOf Student) holdsDuring (GregorianYearFn 2011))
Another solution is to define Student as a 'role' instead of as a
subclass of 'Person' and make 'role' disjoint with 'class'. Then
a statement such as
(Joe hasRoleDuring Student (GregorianYearFn 2011))
could be stored. [Make it more complicated if you like triples.] (06)
> With respect now to the problems in dealing with individuals, I am
> surprised you have never been faced, e.g., with an apparently stupid
> but concrete problem like that of giving meaningful "names" to the
> instances created at run time - apart, of course, of systematically
> choosing the easy way of always creating individuals
> in the "concept_214" style. (07)
Why should anyone care about the names that are used internal to
the running of a computer program? (08)
Database administrators are not concerned about the "names" that
a database uses during the running of a merge -- or any other process.
They care that they can access the data, by whatever key they choose
to use. (09)
If because of your 4D philosophy you find that you are creating large
numbers of 'qua-individuals' for each individual (the "instances
created at run time" that you refer to) -- maybe one for each
event or relationship that that individual is involved in, and find a need
to assign permanent names for them instead of having 'blank nodes',
perhaps your model is not the best one to use for your purpose. (010)
Maybe instead of using that "Golden Hammer" on a problem that deals
with ropes and pulleys, it might be useful to investigate a different tool. (011)
-- doug foxvog (012)
> Regards,
> G.P. Zarri (013)
> On 05/10/2012 19:25, John F Sowa wrote:
>> Dear Gian Piero and Simon,
>>
>> I addressed my previous note to Matthew, but I forgot to comment on your
>> notes, which Matthew was responding to.
>>
>> GPZ
>>> ... 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)?
>>> The management of individuals is particularly tricky and costly in
>>> concrete KBs. (014)
>> There is a huge difference between individuals and types of individuals.
>> There are billions of individuals (AKA "named entities") that must be
>> considered in large databases and the WWW. Facebook alone recently
>> reached the milestone of a billion users, but they manage their types
>> and roles of users very well. (015)
>> Facebook doesn't do any deep reasoning, but Cyc has the largest formal
>> ontology on the planet. Their hierarchy includes all the types of
>> individuals, relations among individuals, and behaviors of individuals. (016)
>> In our work with conceptual graphs (at VivoMind), we maintain large
>> hierarchies of graphs, which we access in logarithmic time. We have
>> processed many terabytes of natural language text. Increasing the
>> numbers of types (i.e., labels on the nodes of the graphs) speeds up
>> the access time. If your system has difficulty with the number of
>> types, you should look for better algorithms. (017)
>> SS
>>> I thought I was being clever, letting meta-properties like "ferpa
>>> directory information release ok" be associated with these student
>>> objects. (018)
>>> Sure, the existence of these role objects may have been rigidly
>>> dependent
>>> on the person job having at some point existed, but I had no idea this
>>> was so modally unacceptable. (019)
>> I prefer the term 'role type' to 'role object'. But there's no problem
>> in having a multiplicity of roles and reasoning about them. (020)
>> When we process and reason with natural languages, we put the concept
>> types for 'father' and 'student' in the same hierarchy with 'human'
>> or 'man'. We make note that there are relational and functional
>> characteristics of fathers and students that are not shared by
>> natural types like human or elephant. (021)
>> But that does not create any problems for the methods of analysis
>> or reasoning. With logarithmic algorithms, going from a thousand
>> types to a million types doubles the access time. No problem. (022)
>> John (023)
_________________________________________________________________
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 (024)
|