> Another element gaining popularity inside the SOA group is the race between
> vendors to sell their version of ESB-Here we go again jumping into the
> quagmire of EAI which was to solve all integration problems. Why not DoD
> take a responsible role in bringing all the vendors together and ask them to
> work together in developing a framework of solutions that can operate in any
> heterogeneous environment. (01)
See the enclosed "Paving the Bare Spots" white paper, which proposes much the
same thing, and the http://giglite.org community, which is starting to come
together with exactly the same goal. (02)
Of course, neither of these directly target the objectives of this group.
We're focused (for now) with the lack of (what I'll call) cross-domain
*syntactic* interoperability, without which *semantic* interopability is
obviously impossible. I'm referring to the lack of agreement on how security
should be handled across the DOD system of systems. (03)
--
Brad Cox, Ph.D: Enterprise Architect, Binary Group
Mail: bcox@xxxxxxxxxxxxxxx; Phone: 703 361 4751
Chat: brdjcx@AIM; Web: http://virtualschool.edu (04)
---------- Original Message -----------
From: "ajit kapoor" <ajitorsarah@xxxxxxxxxxxxx>
To: <rick@xxxxxxxxxxxxxx>, "common upper ontology working group"
<cuo-wg@xxxxxxxxxxxxxx>
Sent: Fri, 9 Feb 2007 10:22:48 -0500
Subject: Re: [cuo-wg] Technical maturity of Semantic Web solution (05)
> I agree, that while DoD and US government in general contribute immense
> resources to information sharing technologies the "knowledge transfer" at
> the pragmatic level has always been slow, and lately it has become "viscous"
> in its practical agility. We are merely experiencing the "Law of large
> numbers" effect. We throw billions on (good concepts) and some of it
> delivers results-all to often late and only benefits a few.
>
> The semantic technology is evolving and there are a lot of good foundation
> behind many of them. The fact that our imagination wants to address all
> possible scenarios should be construed as a positive and motivate us to
> start small and permeate into key environments. DoD has the resources to
> establish such an environment. The problem I believe is a myth that has been
> spread that commercial entities are efficient and therefore lets use COTS.
> Having worked in many industries for 39 years - Xerox, Mead, Burroughs,
> Dataquest/Gartner, META Group, general Motors, Allied Signal, (now retired
> from Lockheed), I can share with you the state is similar to that of the
> Government. I used to joke in my earlier days when I was a consultant that
> we borrow your watch and tell you the time. The relationship between the
> government and industry is very similar.
>
> The issue of SOA -Snake oil Arch" is again result of our own creation. Why
> is there a separate group looking into SOA/WS, Enterprise Architecture, FEA
> vs. TOGAF, and another one into GIG/Netcentric, another one to E-Business,
> and Home Land security has yet another set of similar projects going.
> Information access should be the umbrella group driving all these
> initiatives and work to consolidate some as there is a lot of redundancy.
>
> Another element gaining popularity inside the SOA group is the race between
> vendors to sell their version of ESB-Here we go again jumping into the
> quagmire of EAI which was to solve all integration problems. Why not DoD
> take a responsible role in bringing all the vendors together and ask them to
> work together in developing a framework of solutions that can operate in any
> heterogeneous environment. It has nothing to do with being a capitalist
> society. Lets get competitive using the same "alphabet" -the value is in
> orchestration of prose and poetry and scientific literature and discovery
> not creating their unique alphabet.
>
> The problem is us. We can have us w/o any changes expect to solve the
> problems as we are the one who keep on creating them-I think Einstein said
> something to that effect.
>
> Lets have a true open conference which is open to all not just the large
> vendors who can afford to keep an active sales force in DC. Because if only
> these folks attend we will never get where our citizens want us to go. Make
> our Nation secure in this new era. No COTs cannot solve them.
>
> With regards,
> respectfully.
> ajit
>
> Sincerely
> ----- Original Message -----
> From: "richard murphy" <rick@xxxxxxxxxxxxxx>
> To: "common upper ontology working group" <cuo-wg@xxxxxxxxxxxxxx>
> Sent: Friday, February 09, 2007 9:49 AM
> Subject: Re: [cuo-wg] Technical maturity of Semantic Web solution
>
> > Hello Jim & Cory:
> >
> > I'll offer an alternate explanation to the challenges we currently face.
> > I don't mean to discount the technical challenges, but I believe
> > there are two additional challenges we also face:
> >
> > 1. A knowledge gap. Let's face it, there's been some great research
> > done, most funded by DoD, and knowledge transfer seems to be lagging.
> > The Markle Foundation has proposed an information sharing institute.
> > Maybe something like a SantaFe Institute for federal information sharing
> > would help accelerate knowledge transfer.
> >
> > 2. A private sector that needs to know where it can go. Right now the
> > channels are clogged with SOA (Snake Oil Architecture) ;-) and XML.
> >
> > These technologies need to be displaced from the channels with
> > alternatives. Maybe some kind of performance based contracting with
> > incentives to promote the use of smart technologies. This approach would
> > have to show up in some RFP's. That will enable the private sector to
> > invest based on a known set of targets.
> >
> > --
> > Best wishes,
> >
> > Rick
> >
> > email: rick@xxxxxxxxxxxxxx
> > web: http://www.rickmurphy.org
> > cell: 703-201-9129
> >
> > Schoening, James R C-E LCMC CIO/G6 wrote:
> >> Cory,
> >>
> >> This model starts with the sound concept (Level-1) and ends with the
> >> technology being 'ready' for implementation. Some organizations fund
> >> research, others pilot emerging technology, but most wait until a
> >> technology is ready before rolling it out across their entire enterprise.
> >> It's true, the technology will further mature, just as a 17 year old
> >> driver, who is ready to drive, will further mature, but that's not point
> >> of the model or the paper.
> >>
> >> One problem the paper hopes to address is that some large organizations
> >> (DoD for one) believe the Semantic Web approach is ready for
> >> implementation and can achieve data interoperability (including at the
> >> semantic level) across large numbers of domains, subdomains, and
> >> Communities of Interest. Such domains are forming, but having minimal
> >> luck creating data models and ontologies, and with virtually no
> >> interoperablity amongst them. DoD recently realized this is not working,
> >> but they think they implemented it wrong. They need to understand
> >> current technology (ready for implementation) can't achieve data
> >> interoperability across large numbers of domains.
> >>
> >> It's a secondary issue as to what might work, if anything, but the first
> >> issue is whether organizations like DoD should continue trying to
> >> implement technology that is not anywhere near being ready to implement.
> >> When DoD bought into the Internet, it had already taken off and proven
> >> its value, scalability, and readiness for broad-scale implementation. I
> >> suggest the Semantic Web approach to data interoperability may be working
> >> on a small scale, but hasn't shown it can scale. Maybe this will come,
> >> but its not here now, and IMHO DoD should not assume they can implement
> >> it.
> >>
> >> Jim Schoeing
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Cory Casanave [mailto:cory-c@xxxxxxxxxxxxxxxxxxxxxxx]
> >> Sent: Friday, February 09, 2007 1:01 AM
> >> To: common upper ontology working group; Schoening, James R C-E LCMC
> >> CIO/G6
> >> Subject: RE: [cuo-wg] Technical maturity of Semantic Web solution
> >>
> >> I would also suggest that the first 'actual system" "flight proven" is
> >> the beginning, not the end of a technology maturing. That is the first
> >> early adopter!
> >>
> >> -----Original Message-----
> >> From: cuo-wg-bounces@xxxxxxxxxxxxxx
> >> [mailto:cuo-wg-bounces@xxxxxxxxxxxxxx] On Behalf Of Pat Hayes
> >> Sent: Tuesday, February 06, 2007 1:09 PM
> >> To: Schoening, James R C-E LCMC CIO/G6
> >> Cc: cuo-wg@xxxxxxxxxxxxxx
> >> Subject: Re: [cuo-wg] Technical maturity of Semantic Web solution
> >>
> >>
> >>>Pat (or anyone),
> >>
> >>
> >> Someone else will have to do this. I have no idea what these distinctions
> >> mean in this kind of a context. When did the WWWeb satisfy a 'proof of
> >> concept' or a 'breadboard validation'? This seems to be about engineering
> >> some kind of device, not letting loose a social method of interaction.
> >>
> >> Pat
> >>
> >>
> >>> OK, if what you describe is a potential solution, at what level
> >>>of technical maturity (using scale below, from the paper) would you
> >>>rate this, and please consider scalability as part of this assessement?
> >>>
> >>>1. Basic principles observed and reported.
> >>>2. Technology concept and/or application formulated.
> >>>3. Analytical and experimental critical functions and/or
> >>>characteristic proof of concept.
> >>>4. Component and/or breadboard validation in laboratory environment.
> >>>5. Component and/or breadboard validation in relevant environment.
> >>>6. System/subsystem model or prototype demonstration in a relevant
> >>>environment.
> >>>7. System prototype demonstration in an operational environment.
> >>>8. Actual system completed and 'flight qualified' through test and
> >>>demonstration.
> >>>9. Actual system 'flight proven' though successful mission operations.
> >>>
> >>>Jim Schoening
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Pat Hayes [mailto:phayes@xxxxxxx]
> >>>Sent: Monday, February 05, 2007 5:52 PM
> >>>To: Schoening, James R C-E LCMC CIO/G6
> >>>Cc: cuo-wg@xxxxxxxxxxxxxx
> >>>Subject: Re: [cuo-wg] The next key question
> >>>
> >>>
> >>>>CDSI WG,
> >>>>
> >>>> Given Pat Hayes' description (below) of what Jim Hendler refers to as
> >>>>"URI-based reference mechanism coupled with the standard for KR and
> >>>>other aspects is aimed exactly at scalability.":
> >>>>
> >>>> The key question now is: Could the above referenced
> >>>>technology (when it matures) be used to achieve semantic
> >>>>interoperability across large numbers of domains (with independently
> >>>>developed ontologies)?
> >>>>Any takers?
> >>>
> >>>Sure. The direct answer to your question is, no.
> >>>BUt that is because your question as posed misses the point: the open
> >>>publication paradigm allows ontologies to NOT be developed
> >>>independently of one another. They will cross-refer, use parts of other
> >>>ontologies, and include references - eventually, one hopes, 'nuanced'
> >>>references - to one another in a global network of semantic hyperlinks.
> >>>And they will do this because to create a useful ontology by re-using
> >>>and linking in this way will be vastly easier than building entire
> >>>ontologies from scratch, in isolation from other ontology building.
> >>>Think of the SWeb as a growing ontology 'library', freelyopen to all
> >>>for modification and re-use. As pieces of this are written and found
> >>>widely useful, the number of links to them (and the economic pressure
> >>>on the community to find ways to preserve them) will grow, ensuring
> >>>their even wider re-use. This effect snowballs on the Web, as we all
> >>>know. As far as I can see, the pressures which make such phenomena as
> >>>YouTube go from nothing to billions of users in less than a year will
> >>>still operate, albeit perhaps at a different timescale, for the
> >>>semantic web also. The semantic web is not just traditional ontology
> >>>engineering with XML added as a kind of afterthought. It is part of the
> >>>Web, and will be governed by Webbish laws of growth and distribution.
> >>>
> >>>Pat
> >>>
> >>>
> >>>>Jim Schoening
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Pat Hayes wrote:
> >>>>
> >>>>> OK, here's my take on that.
> >>>>>
> >>>>> First, "standard for KR". I think all that Jim means is, the SWeb
> >>>>>is intended to use whatever is the best available KR mechanism that
> >>>>>can be adopted as a 'standard', ie which a wide enough spectrum of
> >>>>>users can be persuaded to agree to use. No such choice will be free
> >>>>>from controversy. OWL wasn't and isn't free from controversy, and
> >>>>>nobody even knows if a large enough community can ever be brought
> >>>>>to consensus on an acceptable Rule language. But assuming that some
> >>>>>WG can get its job completed, and produces a useful notation, then
> >>>>>that can be used on the SWeb. There are plenty of potential
> >>>>>candidates
> >>>
> >>> >> which are way more expressive than OWL readily available. So it
> >>>would
> >>>
> >>>>> be a mistake to identify the SWeb vision with OWL or DL technology
> >>>>>in particular. OWL-DL is just the first in what one hopes will be
> >>>>>an evolving series of KR standards which will provide the
> >>>>>infrastructure of the SWeb. Perhaps the next one will be more like
> >>>>>Python+Prolog on steroids. Or it may be a breakthrough in CL
> >>>>>reasoners using the guarded fragment, who knows?
> >>>>> The decision is as much political as technical, or even subject to
> >>>>>whims of intellectual fashion.
> >>>>>
> >>>>> "URI-based reference mechanism" is more interesting. This is one
> >>>>>of the few things that really is new and different about the SWeb:
> >>>>>it is part of the Web, and subject to Web conventions and
> >>>>>protocols. It isn't *just* applied ontology engineering. So, every
> >>>>>SWeb ontology is required to use names drawn from a (literally) global
> >>>>>set of names.
> >>>>> The scope of these names is the entire Web. There are no 'locally
> >>>>>scoped' or 'private'
> >>>>> names on the Sweb. So if your ontology uses a name for a concept,
> >>>>>my ontology can use it too.
> >>>>> Anyone can 'say' anything about everyone else's concepts, on the
> >>>>> Sweb.
> >>>>> This is a whole new game, which nobody has played before. A can
> >>>>>introduce a concept called A:thingie1 and B can introduce
> >>>>>B:thingie2, and C can then, entirely independently and without
> >>>>>asking for A or B's permission, assert that (say) A:thingie1 is
> >>>>>the same as B:thingie2. A
> >>>>
> >>>> > and B may disagree: tough tittie, they can't stop C from making
> >>>>the
> >>>>
> >>>>> assertion. C can say things about A's ontology, in fact, such as
> >>>>> assert that it is all BS. The globality of the namespace has a
> >>>>>whole
> >>>>> range of consequences which we are only beginning to explore. And
> >>>>> being URIs (actually IRIs these
> >>>>> days) , these names can also be used as identifiers which *access*
> >>>>> things on the Web.
> >>>>> Whether these accessed things should be the referents of the names
> >>>>> is currently controversial (I think not, in general), but that
> >>>>>they
> >>>>> access
> >>>>> *something* is not even remotely at issue. So SWeb concept names
> >>>>> have a whole new dimensionality to them, which is (or at any rate
> >>>>> can be) orthogonal to their use as referring names. In particular,
> >>>>> it allows ontologies to "address" other ontologies (a pale version
> >>>>> of which is the OWL:imports primitive, but one can do a lot more
> >>>>> than this), which obviously has many potential applications
> >>>>>relevant to scaling.
> >>>>>
> >>>>> Hope this helps.
> >>>>>
> >>>>> BTW, I entirely agree with Jim's optimism. I think people are way
> >>>>>too scared of inconsistencies. Lets wait and see what problems
> >>>>>actually crop up before trying to solve or avoid ones that we only
> >>>>>worry about rather than actually find.
> >>>>>
> >>>>> Pat
> >>>>>
> >>>>
> >>>>___
> >>>
> >>>_________________________________________________________________
> >>>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
> >>
> >>
> >>
> >> --
> >> ---------------------------------------------------------------------
> >> IHMC (850)434 8903 or (650)494 3973 home
> >> 40 South Alcaniz St. (850)202 4416 office
> >> Pensacola (850)202 4440 fax
> >> FL 32502 (850)291 0667 cell
> >> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
> >>
> >>
> >> _________________________________________________________________
> >> 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
> >>
> >> _________________________________________________________________
> >> 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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > _________________________________________________________________
> > 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
> >
> >
>
> _________________________________________________________________
> 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 ------- (06)
Paving the Bare Spots.pdf
Description: Adobe PDF document
_________________________________________________________________
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 (01)
|