Brad, (01)
I agree with your comment on pure top-down approaches, mainly because
nobody has ever managed to solve such a problem in a complex domain,
much less in the hyper-complex domain under consideration. Your
alternative, unfortunately, seems rather worse. (02)
Brad: "But mainly because people just don't solve ontology differences
that way in the real (non-IT) world. They just buy a dictionary, or hire
a translator.
Problem solved." (03)
That's totally unsuitable for the tempo of military operations, and
probably for almost anything else. Interoperability has been a problem
for the military at least since Alexander, and probably much longer.
The traditional (pre-computer) solutions have been standardization,
regimentation, and a rigidly hierarchical data flow structure. I assume
that the reason that there is a CDSI is the demonstrated failures of the
traditional structure in modern operations. (04)
The most successful model we have for interoperability is the brain, and
it features a rich mixture of top-down and bottom-up approaches to
information integration. The biggest virtue I see to W3C, aside from
incorporating that same idea, is that these guys are actually trying to
solve real world problems, and have a proven track record. Trying to
create a working system out of Executable English (or any other version
of first order logic), or any logic, topos theory, or whatever, might be
amusing but is unlikely to solve any real world problems anytime soon. (05)
If interoperability is a real goal, one needs to look at real world
interoperability examples, and see where they fail. I don't think we
can neglect the institutional problems stemming from a large number of
competing groups each trying to create their own interoperable
architectures, often for their own proprietary or institutional reasons.
W3C may not have thee answer to this problem, but it does have an
approach, and a philosophy. The approach incorporates two simple ideas:
a flexible hierarchy of protocols and self-description for both data and
protocol. (06)
Ed (07)
-----Original Message-----
From: cuo-wg-bounces@xxxxxxxxxxxxxx
[mailto:cuo-wg-bounces@xxxxxxxxxxxxxx] On Behalf Of Brad Cox, Ph.D.
Sent: Monday, November 20, 2006 1:38 PM
To: rick@xxxxxxxxxxxxxx; common upper ontology working group
Subject: Re: [cuo-wg] White Paper (08)
Thanks for the encouraging note, Richard. I'd backed off, convinced I'd
wasn't being heard. But buoyed by your note, I'll take one more shot at
explaining what I've been trying to get across. (09)
One of the things that's confusing me is I don't feel I understand what
people mean by the term "N^2 problem". I'm guessing that's shorthand for
costs increaases as limitOf(N*(N-1)) as N -> infinity = N^2. Fair
enough; its shorter. (010)
But that applies if all N machines are to be connected to all N-1
others.
Actually cost increases as the number of *interfaces*. N^2 is just an
upper bound on that. But why concentrate on the upper bound when
interfaces could be counted as easily, without the concern over whether
upper bounds are realistic? For example, for N machines in a linear
pipeline, the number of interfaces is N-1, hardly N^2 or even N*(N-1). (011)
So rephrasing the problem as one of semantic interoperability between M
interfaces where M is larger than we might like but still far less than
N*(N-1). I been trying to point out that there are two ways of
approaching that problem. I've called them the designed approach and the
evolved approach. (012)
In the designed approach, a (small) community of experts uses high
technology ontology tools to build a generalized solution (upper
ontology) that can generate the mappings needed to make any given
interface interoperable. The approach doesn't much depend on what
standard (language) is used. I used OWL as my example because that's
what I'm most familiar with. Structured English, structured french, or
plain ol' Java/Cobol/Haskel would do about as well, albeit with varying
readibility. What's important here is that the approach is centrally
planned, largely confined to an expert community, although hopefully
with at least some support by domain experts with conflicting demands on
their time. (013)
The evolved approach is entirely different and more bottom-up. M
interfaces imply there are M groups of individuals that care about
making each specific interface (call it M(i)) interoperate. Those M
groups are empowered
(governance?) to address the problem in much the same way we solve
inteoperability with natural languages; by using dictionaries and
related tools, using interpreters, etc. Dictionaries and interpreters
are evolved systems. Externally these are commercial products that
compete with each other in a competive system (free markets). But I
could well imagine that domain experts within govt might produce
translation dictionaries that might compete in a similar way, if govt
could find a way to incentive them to focus on the problem over other
pressing uses of their time. (014)
Point is, I could well see how the second (evolved) approach could
"solve"
the interoperability problem" as I've stated it. I've much less
confidence (approaching zero) that the designed approach (as I defined
it) ever could.
This is partially because AI technology just isn't very smart, and
partially because you still need domain experts and don't have a way to
incentive them to contribute, since you've counted too heavily on high
technology as the sole solution. (015)
But mainly because people just don't solve ontology differences that way
in the real (non-IT) world. They just buy a dictionary, or hire a
translator.
Problem solved. (016)
--
Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu (017)
---------- Original Message -----------
From: richard murphy <rick@xxxxxxxxxxxxxx>
To: cuo-wg@xxxxxxxxxxxxxx
Sent: Mon, 20 Nov 2006 13:03:24 -0500
Subject: Re: [cuo-wg] White Paper (018)
> Hi Pat, Brad & All:
>
> I missed the beginning of this conversation, but couldn't resist an
> opportunity to jump into the mix. There's some common ground here
> between Pat and Brad, but the conclusions we draw from the postings
> below are significant.
>
> Pat: I don't interpret your posting to mean we should all use OWL.
> Please correct me if I'm wrong, but I think you're just saying
> standardization within a specific language provides for convention, so (019)
> we can parse, validate and reason.
>
> Would you agree Brad's evolved system implies more than one language
> and interpretation across languages?
>
> Brad: Your point regarding evolved sytems is an important one that
> should be fully explored in the context of CUO-WG. I'd suggest the
> language of complex adaptive systems provides for rich conversation in (020)
> the context of CUO: evolution, adaptation, surviveable, fitness,
> generative, are all great discussion points typically missing here ...
>
> Scanning your prior postings, I'm more inclined to believe there's
> progress at hand regarding automation and the human element in system
> evolution is not one of intervention, but overcoming a knowledge
> barrier in the philosophy and logic from which our systems are
designed.
>
> PH> Hey, hold on. The point of OWL is to provide a
> > standard for ontology information exchange, not a > centrally
> planned ontological technology. There > is no standard, centrally
> planned OWL reasoner or > OWL tool kit: indeed, they should evolve in (021)
> just > the way you describe. But without having a common > language
> to communicate in, the evolutionary > process can't even get started. (022)
> Just as you can't > have much of a free market if there is no >
> standard currency.
>
> BC >The point is designed systems and evolved systems arise from two
> ways of >solving similar problems. Evolved systems ("free markets"
> for example) often >solve the hardest ones better, as the soviet
> economy's shot at central >planning shows.
> >It was also an evolved problem that has pretty much solved the N^2
> problem of >cross-domain ontologies between diverse real languages,
> a problem I think we >do agree won't be solved by centrally planned
> technologies like OWL.
> (01)
>
> --
> Best wishes,
>
> Rick
>
> email: rick@xxxxxxxxxxxxxx
> web: http://www.rickmurphy.org
> cell: 703-201-9129
>
> _________________________________________________________________
> Message Archives: http://colab.cim3.net/forum/cuo-wg/
> Subscribe/Unsubscribe/Config:
> http://colab.cim3.net/mailman/listinfo/cuo-wg/
> To Post: mailto:cuo-wg@xxxxxxxxxxxxxx
> Community Portal: http://colab.cim3.net/ Shared Files:
> http://colab.cim3.net/file/work/SICoP/cuo-wg/
> Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/CommonUpperOntologyWG
------- End of Original Message ------- (023)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/cuo-wg/
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/cuo-wg/
To Post: mailto:cuo-wg@xxxxxxxxxxxxxx
Community Portal: http://colab.cim3.net/ Shared Files:
http://colab.cim3.net/file/work/SICoP/cuo-wg/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/CommonUpperOntologyWG (024)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/cuo-wg/
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/cuo-wg/
To Post: mailto:cuo-wg@xxxxxxxxxxxxxx
Community Portal: http://colab.cim3.net/
Shared Files: http://colab.cim3.net/file/work/SICoP/cuo-wg/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/CommonUpperOntologyWG (025)
|