SUO: Re: Missing Ingredients
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
MI. Note 7
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
Tom,
I am still po(u)ring through that pervious cascade of
a Niagra Falls riverbootlessgambol that you baptized
all of us with yesterday -- I saw on the News last
night that it is apparently possible to make that
descent and live to pay the citation, but I'm no
copycat publicity-or-perish type-seeker when it
comes to a dumb stunt like that, so I will just
register this spate of sentences on my pushdown
stack and troll my context-free dingey-an-sich.
| Some like it cold,
| some like it hot,
| some like it in the pot,
| nine days old.
I know that some people are always requesting that
my poses be longer, albeit fewer and far betweener,
but I, for 1, like 'em shorter, more interoperatic.
Jon Awbrey
Tom Johnston wrote:
>
> Since many fine minds have written many fine words attempting to answer the
> first of your questions, or its near semantic cousins, and since those
> questions still remain open for discussion, I'd like not to discuss them.
> Actually, I'd like to discuss them when I'm wearing my philosopher's hat
> but, in this thread, I'm wearing my database architect's hat.
>
> So I'd like to discuss your second question, which I paraphrase as my #1
> immediately below, and then add a second question. To wit:
>
> 1. What is the meaning of a database table?
>
> 2. How can we formalize that meaning?
>
> I think the answer to the first question is pretty simple (a dangerous thing
> to say, of course). The meaning of a database table is the set membership
> conditions for that table. To take my usual example, here's one definition
> of customer:
>
> a) someone who has purchased a product or service from us;
> b) within the last five years.
>
> "Someone" needs a little clarification, but "legally eligible to enter into
> a purchasing transaction" seems good enough a clarification, finessing
> individuals, married partners, non-profit organizations, LLCs, corporations,
> governmental agencies, etc.
>
> I think the answer to the second question is the Holy Grail we and the
> semantic web folks are pursuing. Do you agree?
>
> Customers serve as a good example. Say that your company's database and my
> company's database both have customer tables. The name of each table is
> Customer. The schemas for the table (defined in the CREATE TABLE statements)
> are identical (or at least commensurate) -- same columns, in the same
> sequence and/or with the same column names, each with the same data type and
> length (or at least capable of storing the same set of values).
>
> This is about all of the meaning of our two Customer tables that existing
> commercial databases can formalize. It pretty much amounts to this, that a
> necessary condition of two tables being semantically identical is that we
> can perform a SQL UNION operation over them. Which shows that very little
> semantics are yet formalized in relational databases.
>
> Let's suppose we run a query across both tables, asking for customers who
> made one or more purchases in the first six months of this year. Can we be
> sure that the result set we get back is what we want? We may be inclined to
> think we know what we are getting (not you and I, of course, but the typical
> user of a business database), because the query seems pretty
> straightforward. But purchases can be booked (recorded as purchases in our
> database) at various points in time -- when ordered, when the product is
> shipped, when the customer's acknowledgement of receipt is received, when
> our invoice is sent, when an initial payment is received, when there is no
> outstanding balance on the bill, etc, etc.
>
> Immersed in the culture of our own company, experienced users may fail to be
> aware of these distinctions. Working with their own databases, their no
> longer conscious assumptions do not mislead. But with a semantic web, and
> the cross-database query possibilities that opens up, no longer conscious
> assumptions will wreak havoc on business decisions based on result sets
> which contain apples and oranges while those who interpret those result sets
> think they contain Granny Smiths and nothing else.
>
> These "no longer conscious assumptions" are part of the semantics of our
> databases, of what we mean by "customer" in this example. Making them
> explicit is not enough. Making them explicit and queryable is the goal.
> N'est pas? Somehow, the way to do this is to register our respective
> Customer tables into a standard hierarchy. In this example, a hierarchy
> which has a Customer node, and enough nodes under its related
> last-purchase-date to make the six distinctions listed above.
>
> I think I understand enough of the issues involved in formalizing semantics
> to realize that the devil is certainly in these details (right along with
> God). Those who think we need an exorcism before jumping into issues like
> making the differences between customer tables available to queries aren't
> wrong in any strong sense. But in trying to make our initial work useful --
> which I offer as a paraphrase of Jim's original question -- my
> recommendation is to try bottom-up for awhile. However, Matthew West, whom I
> thought might have both the inclination and opportunity, seems to have
> neither. I have the inclination, but as a hired gun rather than a long-term
> permanent employee of some company, I don't have the opportunity.
>
> My plea for doing SOMETHING bottom-up is that I think we could indeed cobble
> something together, and learn something in the process. What we learn in
> this basement-floor level ontology effort might even be applicable to the
> development of an SUO. Enough of such bottom-up efforts, once they
> generalize (supertype) to reach mid-level ontological strata, might even
> help us decide such upper level issues as whether a 4D ontology is more
> useful for our purposes than a 3D + time ontology, whether to represent time
> as continuous or discrete, or such mid-level issues as deciding when to
> represent differences as different roles of the same type or as different
> subtypes of the same type.
>
> Enough for now. To my surprise, I find myself
> re-engaging in the conversation.
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o