Ed, (01)
Your note convinced me that Plan B is inevitable. (02)
EB
> You are only talking about pure efficiency in terms of
> machine cycles per byte. (03)
No. Performance is certainly an important aspect. But when I
was talking about the computational structure, I meant everything
that has to do with design, implementation, maintenance, flexibility,
interoperability, human factors, *AND* cost per byte or LOC. (04)
And when you have a fundamental flaw in the underlying design,
it shows up in every one of those aspects. (05)
> I misread your technical characterization as a general condemnation of XSLT. (06)
Please note that I am not condemning XML, which is very useful for
marking up documents. I have been using the *ML family of languages
since the 1970s. And I admit that there are useful applications of
XSLT for many purposes. But processing RDF is *not* one of them. (07)
The first weakness of RDF is that somebody has to *parse* RDF/XML.
Nobody except compiler writers parse the language(s) they use. (08)
It's true that people who process web pages extract info from them.
But if they're using JavaScript and schema.org tags, they just call
a simple routine that takes all the info from those tags and puts
them in a nice clean JSON data structure. (09)
That is why schema.org will destroy RDF/XML. That day is not far off.
If the Semantic Web is going to survive, the W3C will have to go to
Plan B. At the bottom of this note, I repeat my modest proposal. (010)
EB
> XSLT is a simple paradigm for doing simple things. The learning curve
> for adequate competence is days. (011)
In an earlier note, Duane answered that point better than I could: (012)
DN
> The problem with XSLT processing is that you have to build 3 internal
> DOM's. One for the XML input, one for the XSLT and a third for the
> output. I used to be the technical chair of XSLT.com and worked on this
> issue for many years. The long and short is that the processing model was
> not quite balanced in favour. Most XSLT processors used xerces.jar to
> parse, which had a default behaviour of passing all valid bytes to the
> content handler which in turn is used to build the DOM. (013)
That learning curve takes quite a few days. If you use schema.org,
that step is reduced to 0 minutes. (014)
EB
> XSLT fills a niche... XSLT is a tool for the 60% of software engineers
> who are of average competence... (015)
No programmers of average competence should *ever* need to parse the
language(s) they use. Google, Microsoft, and Yahoo! know that. And
that's why they collaborated to form schema.org. And that's why the
Semantic Web will either die or adopt Plan B. (016)
EB
> But GM sees 30000 XML messages a day, and they do use XSLT to translate
> them to standard forms. (017)
I don't know how GM uses XML, but if they have any smarts at all, they
probably have experts write subroutines that generate and analyze the
XML messages. The "average" programmers receive and send messages
by calling those routines from their favorite programming languages. (018)
IBM used XML to define UIMA messages, and they donated all the UIMA
processing code to the Apache Foundation. The UIMA documents say
that the primary language is Java and that the tools for analyzing
and generating the XML are driven by lots of menus. (019)
UIMA starting guide: http://uima.apache.org/doc-uima-annotator.html (020)
EB
> So the next great technology is RDF/JSON? Or is it CL/JSON? (021)
JSON is assumed. But JSON requires semantics. Since CL is
upward compatible with the RDF LBase, it's the obvious choice. (022)
But I worked at IBM long enough to know that management always
has the opportunity to do something stupid. And that was when
IBM was considered "the best managed company in the world." (023)
John
___________________________________________________________________ (024)
Plan B: (025)
1. Phase out RDF/XML as the official base for RDF. There is
no need to say that it's "deprecated". A softer term would
be IBM's euphemism "functionally stabilized". (026)
2. Adopt JSON notation as the official base, but define a formal
semantics for JSON. Pat Hayes collaborated with Guha to define
the logic base (LBase) for RDF. Pat also worked on the ISO
project for Common Logic (CL) and defined the CL model theory
as an upward compatible extension to LBase. Define the JSON
semantics by a mapping to CLIF (Common Logic Interchange Format).
CLIF uses a LISP-like notation that has an almost one-to-one
mapping from JSON. (027)
3. Use the CL semantics to define other useful logic languages
as extensions to JSON. One example would be a version of OWL
that uses JSON. Another would be a rule language that uses
a Horn-clause subset of CL with a syntax based on JavaScript. (028)
4. The option of writing N-tuples in JSON can support a direct
mapping to and from the tables of a relational database.
The rule language could include a version of Datalog to state
SQL queries, constraints, and updates. The types defined by
schema.org would be a valuable enhancement to SQL. (029)
_________________________________________________________________
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 (030)
|