For once we agree, although I must say I think the analogy to Roman numerals is
One thing: (03)
Paul (Tyson) wrote:
> the overall benefits of representing enterprise knowledge in XML far
> outweigh the cost of the extra markup. (04)
That may be true of representing enterprise knowledge IN MESSAGES, i.e., IN
FLOW, but there is no evidence of its being true of representing enterprise
knowledge IN REPOSITORIES. The relationship between access methods and XML is
at best crude, e.g., by comparison with RDBs and some very powerful linking
structures. That is why John talks about the Google repositories. The value
of enterprise knowledge in repositories is very much dependent on its
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
> Sent: Thursday, February 06, 2014 2:11 PM
> To: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] fitness of XML for ontology
> Paul, Duane, and Andrea,
> Before making specific comments, I want to emphasize three points:
> 1. XML is an excellent notation for formatting and annotating
> documents (online and printed). It can be useful for other
> purposes. But edicting it for everything is a bad idea.
> 2. Legacy systems became legacies because they served a useful
> purpose. They should not be discarded lightly, and their
> replacements should support a graceful migration path. For
> many purposes, the SW notations are an important legacy.
> 3. The analogy of computer notations with Roman numerals, decimal,
> and binary arithmetic applies at every level -- from teaching
> first grade up to and including the most advanced R & D.
> > When you say W3C specs that use normative XML definitions are overly
> > complex, defective, or useless, you apparently mean "for direct use by
> > logic programmers"
> No. I meant that XML-based notations are overly complex for
> *everything* outside their "sweet spot" -- point #1 above.
> > it is trivial to down-translate XML to any leaner notation
> Note point #3: It is trivial to down-translate Roman numerals to decimal or
> binary. But it is *easier* to translate the better notations to Roman
> numerals. And note Duane's point below.
> > the overall benefits of representing enterprise knowledge in XML far
> > outweigh the cost of the extra markup.
> No. The Google R & D people know a lot about the data on the WWW and
> how to process it efficiently. Among them are R. V. Guha, who developed
> the original RDF (for which Tim Bray defined the XML).
> Google's solution was Schema.org for the ontology, JSON for the data, RDFa
> for linking the data to the documents, a migration path *from* RDF & OWL,
> and a suite of proprietary tools for doing the processing.
> I believe that the first four (Schema.org, JSON, RDFa, and a migration
> path) are an important step in the right direction. But there are excellent
> tools -- open source and commercial -- that can be used instead of or in
> addition to Google's.
> > [Translating to and from XML] is not "trivial". There are actually
> > data fragments or structures that are not supported directly by Xml
> > without some creative hacking.
> Tim Bray, the original designer of RDF/XML, admitted that he could not
> translate by hand a set of triples to syntactically correct RDF/XML.
> > The people who wrote the specifications (Charles, Jon, Tim et al) are
> > all very smart and gave XML a lot of serious thought.
> I certainly agree. It was an interesting experiment. But they should have
> promoted a design competition before attempting to standardize it.
> > One can easily argue that any programming language, any DSL that needs
> > to specify variables, SQL or SPARQL, or whatever, are not human-friendly.
> > I agree but mainstream IT has certainly adopted arcane and complex
> I agree. At one time in my life, I could read System/360 Hex dumps.
> Some people could insert Hex patches in running systems. And hackers
> (white hat & black hat) are experts in such exploits. But whenever possible,
> simple and readable are better than arcane and complex.
> > The issue comes down to tooling and training, and standards and
> > conventions that the tooling and training can build against.
> Exactly! When Google and the W3C take different paths, I'm not betting on
> the W3C. In many cases, endorsement by the W3C shows that Google's
> steps *away from* the XML-based tools is a good idea.
> 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-
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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 (08)