On 2/6/14 3:03 PM, Cory Casanave wrote:
> 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
> -Cory Casanave (01)
>> -----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
>> 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
>>> [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
>> 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/
> 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
Founder & CEO
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen (06)
Description: S/MIME Cryptographic Signature
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 (01)