Paul, Duane, and Andrea, (01)
Before making specific comments, I want to emphasize three points: (02)
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. (03)
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. (04)
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. (05)
PT
> 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" (06)
No. I meant that XML-based notations are overly complex for
*everything* outside their "sweet spot" -- point #1 above. (07)
PT
> it is trivial to down-translate XML to any leaner notation (08)
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. (09)
PT
> the overall benefits of representing enterprise knowledge in XML
> far outweigh the cost of the extra markup. (010)
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). (011)
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. (012)
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. (013)
DN
> [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. (014)
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. (015)
DN
> The people who wrote the specifications (Charles, Jon, Tim et al)
> are all very smart and gave XML a lot of serious thought. (016)
I certainly agree. It was an interesting experiment. But they should
have promoted a design competition before attempting to standardize it. (017)
AW
> 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 languages. (018)
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. (019)
AW
> The issue comes down to tooling and training, and standards and
> conventions that the tooling and training can build against. (020)
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. (021)
John (022)
_________________________________________________________________
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 (023)
|