xml-dev - RE: RDF, the "semantic web", and the nadir of AI (was RE: Realist icprop

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Perhaps it is better if the vision is put aside long enough 
to understand what the proposed technology offers.  If we 
cast that as a service, which should, as an inventor of 
SOAP interest you, then we can talk about how that service 
responds to requests from an editor.  

You propose a good use case.  On the other hand, database 
forms enable manipulation of strucutres and enable the 
application of pre-defined schema relationships without 
the need to resort to RDF.  What you are describing sounds 
a lot like WYSIWYGNextGen.   WYSIWYG depends on a fixed 
set of internal structures that are presentation-oriented 
and that level does not improve our capability so I assume 
you have something more capable in mind such as direct 
editing of extensible structures, that is, the problem 
with WYSIWYG and the reason for the re-emergence of markup 
was the inability to extend the structures and repurpose 
the information.   If I understand this correctly, topic 
maps, RDF, etc. are an independent means to ascribe such 
structures by pointing into the information, thus they 
act similarly to a view where the SQL infers the meaning 
by in the context use (code that calls the SQL statement).

What messages would a SOAP dispatcher/listener for an 
online editor (application service provider software, perhaps)
use with the RDF engine?  Would that improve the current 
forms-based editing and if so, how?

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Dave Winer [mailto:dave@userland.com]

To me, a writer and software developer, the first thing is a tool. The HTML
web would have been nothing but academic research if there were no
browser-editor and server. I extrapolate that if the Semantic Web doesn't
have a browser-editor (the hard part, serving is probably just HTTP) then no
one can really know what it is.

The key thing about a browser-editor is that it understand and allow easy
manipulation of structures that contain text, instead of text that contains
markup. The "semanticness" of it should be hidden behind an intuitive
interface that gets the writer to create meaningful relationships between
information, without understanding the underlying technology at a deep
level.

I think from there the format questions, which have been so hotly debated,
become easy -- what format does the browser-editor dictate?