John: (01)
I have never advocated XML should be used for everything, even during the
time I had XML Global, my first startup ;-) (02)
The XML encoding of RDF is fairly easy as there is a specification for it
that encompasses the logic. There are many models that do not allow
themselves to be easily encoded in XML. (03)
On top of that, there are many shortcomings of XML and XML schema that
need to be prescriptively described within the XML processing model.
Otherwise, there is ambiguity although in practice, if everyone used the
same parser libraries, the problem is much smaller than it could be. (04)
Duane (05)
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanenickull (06)
On 2014-02-06 11:11 AM, "John F Sowa" <sowa@xxxxxxxxxxx> wrote: (07)
>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.
>
>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"
>
>No. I meant that XML-based notations are overly complex for
>*everything* outside their "sweet spot" -- point #1 above.
>
>PT
>> 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.
>
>PT
>> 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.
>
>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.
>
>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.
>
>DN
>> 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.
>
>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.
>
>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.
>
>AW
>> 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.
>
>John
>
>_________________________________________________________________
>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
> (08)
_________________________________________________________________
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 (09)
|