Re: Learning from other disciplines?

On Fri, Feb 27, 2009 at 2:41 PM, Booth, David (HP Software - Boston)
<dbooth@hp.com> wrote:
>> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
>> [ . . . ]
>> This AKT example has been mentioned too many times
>> and it is clear that independent of any 'introduced' ambiguity, the
>> modeling choice is unexplained
>
> Of *course* the modeling choice is unexplained.  I already made it clear that the point of the example is not to debate modeling choices.  The point is to address the question: *given* that something was modeled as an individual, and its interpretation turns out to be ambiguous (to some applications), how can the relationship between that term and more specific terms be indicated in a general way?

We start at a different place. I want the modeling to be front and
center, and to go and fix it when it is broken.

>
>>  and incoherent from the getgo. No
>> amount of patching will fix it.
>
> Wrong.  The whole point of the "splitting" paper is to point out that all is *not* lost when this kind of problem inevitably occurs.  An ambiguous term can be related to more specific terms without breaking applications that may still be using the ambiguous term.

I don't see how this works. I would need to understand what you think
breaks applications, for instance.

>> I note that David given *no* definitions for any of the terms he uses.
>> Shall we at least agree that minimal documentation of the terms one
>> uses, in natural language, is a universally applicable good modeling
>> practice? At least when attempting to write in a scholarly way about
>> modeling?
>
> Since I already pointed you specifically to the descriptions of s:isBroaderThan and s:isNarrowerThan, I assume you are now referring to the terms http://jann.example#akt http://luke.example#akt1, http://luke.example#akt2 and http://luke.example#akt3,
> It should have been evident that, beyond knowing that they are being modeled as *individuals* (which is clearly stated), the precise descriptions of those terms are completely irrelevant to this problem and thus were omitted.

What are those individuals? That's relevant as in order to assess how
applications would behave it would seem I would need to know that. Or
in your terms - what is the URI declaration of AKT?

However, I realize that while I read the definition of broader and
narrower, they didn't register because they don't make sense to me. So
my bad - there are definitions. Just not ones that make sense.

s:isBroaderThanDeclaration indicates that the subject
        URI declaration is broader than the object URI declaration,
        which means that any resource that satisfies the constraints
        expressed by the object URI declaration also satisfies
        the constraints of the subject URI declaration.
        See http://dbooth.org/2007/uri-decl/#precise-def-uri-decl .


Why don't they make sense? a) Because they are circular
(isBroaderThanDeclaration ... "is broader than the object URI
declaration". and b) Because they make reference to some idea of
"constraints" that I have no idea how to evaluate. As I mention above,
you don't give URI declarations for the terms used in the examples, so
I can't even try to reason from the concrete.


>
>>
>> > If you believe that ambiguity can be entirely eliminated by
>> > "good practice",
>> > then I venture to suggest that your advice will be one of
>> > the enduring
>> > problems for future knowledge workers.
>>
>> I don't believe I said that. I said that in this case one needs not
>> bring in any new terminology to see what's gone wrong - that applying
>> basic knowledge of how to model (starting with saying what your
>> instances mean) leads to a situation in which one needs not introduce
>> Dave's hacky solution.
>
> Hacky?  Perhaps.  But I haven't yet found a more elegant solution.  If you have suggestions -- for *this* problem -- I'd be interested.  Here is a restatement of the problem, using BLU instead of AKT, since you seem to dislike the AKT example:
>
> Suppose a term http://example#BLU is defined and modeled as an *individual* -- not a class -- and it later turns out that for some applications it is ambiguous: there are three plausible interpretations of the term.  New terms http://example#BLU1, http://example#BLU2 and http://example#BLU3 are later defined corresponding to these three interpretations, i.e., more axioms are added.  Thus, the set of plausible interpretations for http://example#BLU1, http://example#BLU2 and http://example#BLU3 are subsets of the set of plausible interpretations for http://example#BLU.

In the OBO foundry when we make a mistake, we fix it. Yes it's a hit
to take. The alternative is worse.

> The question: How would you describe, in RDF, the relationship between http://example#BLU and the new terms?

As you may have already discerned from previous conversation, I don't
represent *anything* in RDF. RDF, in my view, has a fundamental
failing, in that there is no way for anything said to be
computationally determined to be wrong.  It further suffers from
having several different views of its semantics - at a minimum the RDF
MT view and the SPARQL view. While it's true that one can't express
close to all one wants to in OWL, at least some things can be, and
tools can (and regularly do) say that there are mistakes, and this is
typically very helpful.

In the example you give I really don't know what to say. I try,
particularly with individuals, to be clear when I create one that I
know what the individual is, or I use an anonymous individual. As
Jonathan notes, Model theory is a worked out theory of ambiguity and
it's hard enough to reason about the consequences of possibility of
different interpretation in an extremely well worked out computational
model. I don't see how working so loosely as this proposal does, with
terms that are difficult to understand and evaluate precisely, is
going to practically help in a scalable way.

-Alan
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
>

Received on Saturday, 28 February 2009 15:48:37 UTC