In many places you talk about XML for " formatting and annotating documents ".
However, its primary mainstream purpose seems to be for externalized/shared
structured data. While xHTML and HTML5 use a legal XML structure, very few
people probably care. XML is about data. I'm not defending it, its complexity
or its verbosity, just recognizing the way it is. JSON seems to be more about
data between coupled applications (A server and client built for that server).
Of course, all of this will change, but ignoring XML data would not seem to be
wise. It would seem a trivial matter to have an XML binding for any ontology
language or data format you may prefer, what is important is the semantics
behind the representation - not the angle brackets. I really don't care much
how people persist and exchange their data (or metadata) as long as the model
is sound. (01)
-Cory Casanave (02)
> -----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
> 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
> -- open source and commercial -- that can be used instead of or in addition to
> > [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 (04)