SUO: Re: Zeroth Order Ontology
when you get to the end of this thread,
you'll find that i moved the spindle
to the ont list, where there are
a few new knots, in order to
focus my attention on the
main to the procedural
in, uh, progress.
i am, incidentally, if not amusingly,
discovering that the semiosphere of
the brain that does procedural is
not at all connected to the one
that does substantive, and so
i'm starting to believe in
your 2-hat theory.
just kidding of course ...
b there or b^2:
Tom Johnston wrote:
> 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.
> -----Original Message-----
> From: Jon Awbrey [mailto:firstname.lastname@example.org]
> Sent: Wednesday, November 12, 2003 1:13 PM
> To: SUO
> Cc: Murray Altheim; Tom Johnston
> Subject: Re: Zeroth Order Ontology
> ZOO. Discussion Note 15
> 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
> o SIO. Semantic Integration Objectives
> o FIL. Formalization In Layers
> 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