> "Pipelines," also known as "stovepipes," are not known to promote
> effective interoperability across systems, much less across domains. (01)
We seem to have miscommunicated. Pipeline doesn't mean stovepipe, certainly
not in my domain. It means a linear chain of nodes, linearly connected by
interfaces. I never proposed pipelining as a solution, but as a concrete
example to show a lower bound (N-1) that is far smaller than the upper bound
(N*(N-1)). Real systems fall somewhere between. (02)
The rest of your argument seems to hinge on that misunderstanding. Any system,
however connected, will have M interfaces between its nodes. The interfaces do
the mappings. Each translation is *NOT* likely to lose or distort information;
each translation works exactly the same way, day in, day out. The internet
would never work if bits degrade along the way. (03)
The question is whether those mappings are derived from some explicit upper
ontology that understands all domains of interest, versus independently for
each interface by pairs of domain experts on each side of each interface. (04)
The first approach relies on high-tech ontology specification and translator
derivation tools. The second one relies on human intelligence (domain experts)
feeding extremely low-tech tools (XSLT or slightly better). (05)
Take your choice. My bet is on humans over AI every time. (06)
--
Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu (07)
---------- Original Message -----------
From: "Haugh, Brian" <bhaugh@xxxxxxx>
To: "common upper ontology working group" <cuo-wg@xxxxxxxxxxxxxx>
Sent: Wed, 22 Nov 2006 18:38:34 -0500
Subject: Re: [cuo-wg] An Evolved Approach to CDSI? (08)
> Perhaps some replies to issues raised by Brad Cox (in quotes) may help
> clarify some of the real problems faced by CDSI, which his proposal for
> an "evolved approach" does not adequately address.
>
> But, those who already feel that they understand the "N^2 problem" and
> its ramifications for Brad's proposal and CDSI may want to skip this.
> __________
> "I don't feel I understand what people mean by the term "N^2 problem....
> for N machines in a linear pipeline, the number of interfaces is N-1."
>
> "Pipelines," also known as "stovepipes," are not known to promote
> effective interoperability across systems, much less across domains.
> Translation pipelines, however, are even worse than traditional
> stovepipe systems, which may share some common internal representations.
> A translation "pipeline" would face the results you get from the
> children's game of "telephone", only worse. Each translation is likely
> to lose or distort some aspect of information obtained from a source
> with different semantic foundations, so by the end the results may be
> unrecognizable.
>
> While we may all agree that you won't have the worst N^2 case in every
> context, you really don't want a lot of linear pipelines translating
> between systems/domains. In addition, capability needs are driving
> requirements for direct interoperability between more and more
> systems/domains. Hence, the N^2 upper bound is a real concern.
> ____________
> "The approach doesn't much depend on what standard (language) is used."
>
> While the definition of the ("designed") approach is indedpendent of the
> language used; I expect all would agree that any success achieved by an
> application of this approach will be strongly dependent on the
> expressive power of the language, as well as its semantic foundations,
> breadth of adoption, adequacy of support tools, etc.
> ______________
> [In] "the evolved approach ...groups...address the problem in much the
> same way we solve inteoperability with natural languages; by using
> dictionaries and related tools, using interpreters, etc."
>
> While unclear, it sounds like the proposed "evolved approach" involves
> point-to-point translations between systems/domains and a competitive
> marketplace for achieving the best translations. If so, it seems to me
> that any faith in such an approach underestimates:
>
> 1) the number of point-to-point translation components required
>
> 2) the difficulty of doing translation between systems/domains with no
> common semantic foundation (you still need the "domain experts" as in
> the "designed approach")
>
> 3) the exhorbitant costs of supporting a competitive market place in
> point-to-point translation components. The market for customized
> components to translate between indivdual systems or even domains does
> not seem adequate to support an effective free market. Providing
> incentives to government employees (or contractors) to produce multiple
> competing translations doesn't sound real cost-effective either. Someone
> has to pay the labor for all those translations (Order K*N^2, where K is
> the number of competing solutions for each pairwise translation).
> General-purpose tools for dictionaries and translation cannot do the
> translations themselves, even if there were a viable market for them.
> __________________
> "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."
>
> This analogy with natural language translation by humans doesn't hold up
> too well for a number of obvious reasons. We don't want to use humans to
> do all real-time translations manually due to costs in labor, time, and
> money. Even existing translations of (& information extraction from)
> human readable natural language text is moving towards automation,
> (e.g., TIDES, ACE, AFE) due to volume and cost issues.
>
> So, I think we all recognize the needs for machines to do the
> cross-domain translations and to use the results for tasks like
> discovery and analysis. But, as acknowledged, machines are not as smart
> a people, so we can't just hand them a dictionary :-). To effectively
> translate and analyze information from multiple disparate sources,
> computers need software translation components that are grounded in
> formal semantics supporting automated inference. But, an "evolved
> approach" dependent on funding a competitive market in machine-readable
> translation components ("dictionaries") for all pariwise unrelated
> languages/systems/domains (which need to interoperate) doesn't sound
> real cost-effective (Order (K*N^2) is a real cost issue).
> __________________
>
> While the "evolved approach" that's been described has long been
> considered a non-starter by many, other concepts of "evolution" and
> "bottom-up" development in semantic interoperability might well have
> something to offer to the CDSI problem. There has been work on
> automating the extraction of ontology elements from text, as well as the
> evolution of ontologies over time to reflect changing usage. The work by
> John Sowa in this area, already cited in this forum, is one example of
> interest. Such approaches have evolved well beyond the simplistic "hire
> a translator" proposal. Still, they seem to need some more evolution
> before they are ready for prime time applications.
>
> And, while the "designed approach" has been dismissed, it has a track
> record of success in promoting data interoperability amongst disparate
> systems. The C2IEDM/GH5/JC3IEDM, which others have mentioned, is one
> good example wherein a multi-national group of domain experts
> collaborated to produce a common information model that serves as the
> "lingua franca" for operational interoperability in Command and Control
> across very different systems maintained by different governments. While
> such efforts have been unfairly disparaged as too "top-down", when
> successful they actually rely heavily on bottom-up inputs from Subject
> Matter Experts working closely with IT folks to get the information
> models to support user needs.
>
> That is not to say that the specific approach taken by the C2IEDM/GH5 is
> adequate for CDSI, as it falls short in its semantic content (being
> inadequate for machine "understanding") and it covers only one domain
> (Command and Control). Still, some variant of the generic "designed
> approach" might be adapted for CDSI by the use of a common upper
> ontology and/or a small set of upper/middle ontologies. But, I.
>
> Brian
> __________________________________________
> Brian A. Haugh, Ph.D.
> Institute for Defense Analyses
> Information Technology and Systems Division Phone: (703) 845-6678
> 4850 Mark Center Drive Fax: (703) 845-6848
> Alexandria, VA 22311-1882 Email: bhaugh@xxxxxxx
>
> > -----Original Message-----
> > From: cuo-wg-bounces@xxxxxxxxxxxxxx
> [mailto:cuo-wg-bounces@xxxxxxxxxxxxxx]
> > On Behalf Of Brad Cox, Ph.D.
> > Sent: Monday, November 20, 2006 3:38 PM
> > To: rick@xxxxxxxxxxxxxx; common upper ontology working group
> > Subject: Re: [cuo-wg] White Paper
> >
> > 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.
> >
> > 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.
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > --
> > Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
> > Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu
> >
> >
>
> _________________________________________________________________
> 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 ------- (09)
_________________________________________________________________
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 (010)
|