ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] AJAX vs. the Giant Global Graph

To: "John F. Sowa" <sowa@xxxxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Edward Barkmeyer <edward.barkmeyer@xxxxxxxx>
Date: Tue, 30 Mar 2010 17:15:22 -0400
Message-id: <4BB269EA.50102@xxxxxxxx>
John,    (01)

I think we are largely in agreement.  Multiple technologies for 
aggregating data of various kinds and creating information for a 
specific viewpoint are a good thing.  AND... when we have multiple such 
technologies, we have to be able to integrate their outputs or their 
agents, to create the next level of information.    (02)

Some minor interjections...    (03)

you wrote:
> EB> The Semantic Web approach is to capture the referential knowledge
>  > formally and derive it in a trusted way.
>
> JS>I fully approve of that goal, but there are many more issues involved,
> than just the use of XML and URIs by themselves.  The fundamental issues
> are semantic and pragmatic.  Syntactic mechanisms, by themselves, can be
> more of an obstacle than a foundation.
>       (04)

Semantic and pragmatic issues are common to both approaches.  The formal 
capture of semantics depends on the primitives, and John has long been a 
proponent of tested upper ontologies.  OTOH, the AJAX conversion of raw 
data to useful information in a view also depends on the assignment of 
semantics to the raw data elements, and that rarely benefits from any 
kind of clear specification.  (NIST has a whole missionary effort with 
respect to the semantics of measurements.)    (05)

Syntactic mechanisms, however, are critical to both methods -- syntax 
regulates the form of expression, and expression is the only means of 
conveying information.  I don't think of syntax as being foundational in 
any sense, but it is only an obstacle when it is inadequate to the task 
of conveying the intended information.  I think what John has in mind is 
that syntax is often constrained to be simple enough to support a given 
processing algorithm, and that objective conflicts with its ability to 
convey the intended information in some, perhaps most, uses.  Natural 
languages, OTOH, have very complex and perhaps ill-defined syntax, which 
makes the problem of interpreting them much more difficult.  Put another 
way, the lack of well-defined syntax is always an obstacle.    (06)

> EB> I fully agree with the idea that we need to "combine [RDF-annotated
>  > information] with other kinds of information", but there are two ways
>  > to do that -- derive the semantic markup for the other kinds, or link
>  > them by statistical association.
>
> JS> Depending on how you count and what you count, there could be many more 
> ways.
>       (07)

Agreed. I overstated that.  We were discussing only two approaches -- 
AJAX and GGG.  And upon reflection, I don't think the AJAX approach is 
intrinsically bound to the Google mechanism for making linkages.  In 
fact, GoogleMaps is probably a counterexample -- there is a conceptual 
schema that is used by the interpreters to markup the data.    (08)

> EB> All the data that is used by AJAX methods is provided by specific
>  > HTTP-accessible services on the servers.  The data is web-accessible..
>
> JS> That is trivially true for that part of the processing that is done
> in JavaScript on the client side.  But there is no such restriction
> on the server, which can do anything with any resource it owns.
>       (09)

My point was that this is not only true of the "server". 
We have a general architecture for the AJAX process as a set of functions:
 - obtain the source data sets
 - convert each source data set to a reference form
 - convert the reference forms to a working repository of 'integrated' 
information
 - develop the view from the repository information
 - display the view in the browser    (010)

We can deploy these functions in any number of 'component' 
configurations.  The functions don't necessarily map 1-to-1 to 
components.  I think there are only two constraints:
 - any data set (including schemas) that is not local to the 
'integrator' must be web-accessible
 - the view display must occur at the client node    (011)

As best I can tell, the first four functions apply equally well to 
Semantic Web architectures.  The only problem is that the SemWeb 
apostles assume that the 'integrator' and 'view development' functions 
are implemented over a few well-defined reasoning technologies, notably 
the OWL extended description logics.  And the current state of the art 
is that the conversion of source data to reference form requires static 
markup.  Thus:    (012)

> EB> The idea of the Semantic Web technologies is that they are
>  > supporting technologies for any of several such architectures.
>  > They require some agent to markup the...
>
> JS> Yes.  They sweep all the hard stuff under the rug -- i.e., they
> leave it to some external "agent", whose semantics is outside
> the specifications and recommendations of the W3C.
>       (013)

But AJAX does the same.  It tells us nothing whatever about how to build 
an adapter -- neither what the source syntax might be, nor what the 
reference form might be, beyond that it is XML, which is only slightly 
better than defining a character set.     (014)

The AJAX idea is that adapters can do the conversion or markup on the 
fly, and that usually requires a fairly simple source syntax and no 
requirement for the adapter to process the source data as a body.  That 
is, "the hard stuff" isn't that hard. John's point is that there is a 
lot of web-accessible data like that (and a lot more that could be), and 
the adapters can also filter for a target application.  The Sem Web 
technology is really designed for situations in which the source syntax 
is complex (like natural language) and may need to be processed as a 
body (a text corpus) in order to get proper markup.    (015)

What I was trying to do, however clumsily, was to tease out the 
requirements, the assumptions, and the net architectural differences in 
what John sees as 'complementary technologies'.  I think we are finally 
getting there.    (016)

> As I've said many times, the SemWeb is too provincial.  Other
> people have said that it suffers from a Not-Invented-Here syndrome.
> They've carved out a little niche and ignored what goes on in
> all the hardware and software that pump out web pages.
>       (017)

That is all true.  But at the same time, they are trying to do "the hard 
stuff", and that is something new.  It is not just recyclying 1980s 
distributed data technologies using Java and XML.  There is a lot to be 
said for reengineering technologies that work.  They aren't 
breakthroughs, but they can have enormous impact.  As Jared Diamond 
observed, it was the _re_invention of the wheel by people who had 
domesticated draft animals that made the difference.     (018)

The SemWeb vision is not 'provincial' -- there is even more text out 
there than simply structured data, and the SemWeb is a means of 
improving its accessibility as information, either as markup or as an 
interpretable rendering.  The problem with the SemWeb is that it is an 
early wheel, and the draft animals are human, so all we can make is 
wheelbarrows.  But we are beginning to see rickshaws, and perhaps we 
will have the breakthrough that bypasses the horse for the electric motor.    (019)

> Bottom line:  The semantics of the Web is intimately connected
> with the semantics of every system connected to the Web.  You
> can't have a web-only semantics or a web-only science.
>       (020)

Amen.     (021)

But the converse is not true.  The semantics of systems connected to the 
Web is not necessarily intimately connected to the "semantics of the 
Web"; many looser couplings are possible.  I would in fact argue that 
Microsoft's effort to make the system-to-Internet relationship seamless 
was a conceptual mistake (not just a technical mess).  I don't come from 
New England, and I know Robert Frost used the adage in irony, but I 
believe that "good fences make good neighbors".    (022)

-Ed    (023)

-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (024)

"The opinions expressed above do not reflect consensus of NIST, 
 and have not been reviewed by any Government authority."    (025)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (026)

<Prev in Thread] Current Thread [Next in Thread>