SUO: RE: Zeroth Order Ontology
Jon:
I'm still having trouble following you, but I'm still trying. A recent email
(sent to you, not the group) indicates the direction I think following the
trail of SIO leads us in. I've gone back and found earlier emails of mine
which expand on the points made in that email. But I can't tell whether you
and I are heading in the same direction (unbeknownst to me because the
language in which you write your travel notes is too difficult for me), or
whether we're heading in substantially different directions.
Noting that I've just alluded to an off-list correspondence, and just in
case anyone is interested, I've copied the following from that email:
Self, in what manner of expression do I intend
| to formulate these "set-membership conditions"?
Ah, here's the "put up or shut up" response. Here is a highly
over-simplified example. It's main virtue is that it describes a way to
achieve a degree of SIO.
a) by means of a hierarchical set of ontological categories. Imagine a
hierarchy of which this is a snippet from the middle:
....... Involved Party ---> Customer ---> Customer of subtype 3.
Other involved parties are suppliers, competitors and regulatory agencies.
For differens definitions of "customer", see earlier emails of mine. Each
node in the hierarchy has a definition in plain English, available to anyone
who browses the hierarchy.
b) Lots of different businesses register their Customer tables under the
appropriate nodes. Some register under Customer-3, some under Customer-8,
etc. The registration means that the definition of the node a specific
Customer table is registered under is true of that table.
c) For now, I skip over formalizing any more than this. I skip over
formalizing the definitions of the nodes. Perhaps there is a glossary of
terms used in the definitions (like the various Barron's dictionaries for
different industries). But all the interpretation is done by human beings,
reading the definitions to decide under which node to register their tables,
then reading them later on to decide which nodes to name in their SQL
queries.
d) Associated with each node is a minimal schema, i.e. the structure created
by a CREATE TABLE statement. Specific customer tables may have more
attributes than those listed in the node's minimal schema, but they do have
at least those attributes (either in the same sequence, or with the same
name -- whichever will establish the attribute-level correspondence with the
minimal schema).
That's all. Now if I want to retrieve a list of customers who live in
Georgia, for example (state of residence being one of the attributes in the
minimal schema), I just review all the nodes under Customer to find the more
specific sense of "customer" that best meets my needs. Suppose that sense is
the one for Customer-3. So I write a query in which the node to be searched
is Customer-3.
A translator goes to the hierarchy, and finds all the tables registered as
Customer-3 tables, and rewrites the query to specifically name those tables.
(If performance were no issue, it might do a PROJECT on those tables to get
down to the minimal schema set of columns, then a UNION on those tables, and
finally run the query against the result.)
Let's say that the query writer realizes that the real customer concept he
is working with requires the customer to have made an invoiced purchase
within the last year. But Customer-3 is a leaf node in the tree, and is the
closest fit to the concept he has in mind. So he adds a selection criterion
to his query, to weed out those who are not customers by the definition he
is working with, i.e. to weed out all those Customer-3 customers who haven't
made a purchase in the last year.
Thus, aiming a query at a node in the tree (possibly leaf node, possibly
not), and then supplementing the definition of "customer" which that aiming
has determined with selection criteria that make the definition more
precise, is a way to specify the semantics of the customer concept the query
writer has in mind, across a possibly very large set of specific customer
tables, residing in databases in his own company and many other companies.
This could be done, pretty easily. If it were done, it would provide
semantic interoperability across different databases. So this is what I mean
by SIO of databases.
The question isn't whether this is a very crude approach or not. It clearly
is. For one thing, it doesn't address the issue with which I made my
entrance into this forum, that of formalizing semantics in a way which
accommodates not just Aristotelian definitions of essences, but also
Wittgensteinian definitions of family resemblances. But I've got an equally
clear (equally superficial?) understanding of how that could be done. And it
would greatly enhance the specificity with which we could specify a concept
to an algorithm that would then search across a multitude of databases to
find instances of that concept.
A further refinement would, of course, be to formalize the language in which
the definitions are expressed. For example by creating a semantic network of
the concepts used in the definitions, and using FOPL whose predicates are
those concepts to specify the definitions themselves.
So please tell me why I need to worry about your three questions in order to
achieve what I've just described. The answer would not be that what I've
described is very crude, and formalizes very little of the relevant
semantics. I concede that. The answer, instead, would have to be that the
mechanism I've just described will fall apart as we try to expand it to
formalize additional semantics. It is, in other words, possibly a minimally
useful throw-away. But it is not a solid foundation, as soon as we try to
achieve more than this minimal bit of SIO.
Tom
-----Original Message-----
From: Jon Awbrey [mailto:jawbrey@att.net]
Sent: Wednesday, November 12, 2003 1:13 PM
To: SUO
Cc: Murray Altheim; Tom Johnston
Subject: Re: Zeroth Order Ontology
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
ZOO. Discussion Note 15
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
Murray, Tom, et al.
In catching up with the backlog of old notes on several threads and
in considering some of your off-list remarks, I realize that it may
be a good thing to review the genealogy or the subgoal hierarchy of
the present thread. My attention span has been so short throughout
the course of my life that I've been forced to devise a large array
of mnemonic devices of an artifactual nature, of which my acronymic
hash codes are but the tip of my cold storage iceberg. Among these
are the trees that I use to record the pragmatic genealogies of all
my objects and objectives.
Here is what I have for the thematic evolution of the ZOO filiation:
@ MI. Missing Ingredients
|
v
o SIO. Semantic Integration Objectives
|
v
o FIL. Formalization In Layers
|
v
o ZOO. Zeroth Order Ontology
A few of these themes arose in discussion and were developed,
either explicitly or implicitly, through numerous generations,
mutations, and natural or nutural selections, for quite a while,
before they came to be assigned differential nomens of their own.
Under the prompting of Jim's Missing Ingredients directive,
an early chorus of wide-ranging consensus, unusual in its
scope for our usual polyphony, chimed in on the theme of
Semantic Inter-Operability, both within and between the
acutely tensed modes of "axiomatic conceptual" versus
"empirical statistical" or "data relational" bases.
Pursuant to the call for "bottom up" approaches to the SIO problem,
I introduced the standard paradigm whose name is legion but that I
am calling "Formalization In Layers" (FIL). The initial lamina of
calculus in the most deeply enscounced oyster of this worldview is
the system that folklore aptly gives the name "Zeroth Order Logic",
and its applications to ontology are naturally enough described as
"Zeroth Order Ontology".
Obviously, there's still a lot to do in the way of
assembling the alimentary ingredients of this stew,
or soup, or haggis, or borsch, or hash, or pudding,
or pasty, or gumbo, or chop-suo, ..., well, assign
the rest to the disputanda of your own disgestions.
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o