On 3/19/12 4:46 PM, John F. Sowa wrote:
> On 3/19/2012 10:55 AM, Kingsley Idehen wrote:
>> I think (as is always the case) you have to distinguish individuals from
>> organizations they build. TimBL != W3C .
> I agree.
> Tim did an excellent job for the original WWW project, when he managed
> a half dozen people to finish the job in one year. The problem with
> a big committee is that "Too many cooks spoil the broth."
> Committees are much better at evaluating and testing alternatives
> -- especially when they have sufficient info from design competitions.
> And the best kind of competition comes from testing implementations
> on actual problems that people pay to get solved.
> The U. of Illinois developed the Mozilla browser with gov't funding
> that forced it to be open source. The original Mozilla designers
> extended the source code for their proprietary Netscape, but other
> groups continued to extend the same source code -- including a company
> that sold their extensions to Microsoft for IE 1.0.
> The problem with that method is that the extensions aren't compatible.
> But there was sufficient experience for the ECMA committee to clean up
> and harmonize the alternatives for ECMAScript. That's the best way
> to use a committee -- harmonize de facto standards that people use.
> The biggest mistake of the W3C was to treat their RFCs (Requests for
> Comment) as if they were standards. (01)
You can prescribe a standard. It's always much better to standardize
retrospectively based on industry use. (03)
Many W3C specs lack contributions from industry, and that's lead to many
> They kept telling people that
> RFCs aren't standards, but they kept treating them as if they were.
> Tim Bray (who collaborated with Guha to design RDF) said that RDF
> was broken back in 1999, but the W3C refused to fix it. (05)
Tim Bray was talking about RDF/XML and the invisibility of the basic
triple pattern re. this particular syntax. By the way, he never really
offered an alternative either. On the other hand, others chugged along
and produced alternative syntaxes leading up the the collection we have
1. N-Triples -- which is very close to CSV if you drop the header row
and use curly brackets for URIs
10. JSON-LD . (07)
>> None of it [Google's tools or IBM's tools] works or is moderately
>> practical re scale of the World Wide Web. They all lead to silos.
> I am not recommending either of them as the ideal solution. I just
> said that we should learn from them. (08)
Nothing to learn from them, really. (09)
A while back Adam Bosworth nearly honed into what is now known as Linked
Data but his suggestion didn't really grasp the fidelity inherent in URI
abstraction re. Name and Address disambiguation en route to using
hyperlinks distinctively for Names of description subjects and Address
of their descriptor resources (or documents). (010)
> In any case, Google scales
> their tools to the WWW, but they don't address the reasoning issues. (011)
They don't address the openness issue either. This is why I say it
doesn't scale. Today, I have to use Linked Data transformation
middleware to integrate Google+ into the burgeoning Web of Linked Data.
I don't need to do that with Facebook since they already just publish
Linked Data. Every data object is endowed with an unambiguous and
de-referencable identifier that resolves to its descriptor document. (012)
> IBM did some interesting stuff on reasoning with Watson. (013)
Yes, re. getting it on TV etc.. (014)
As for the computing power needed to deliver the results. I am far from
impressed. I would like to see IBM publish a live Graph DBMS that the
world could perform entity analytics against. Something in the range of
29 - 50+ billion relations. Not just IBM, and of the behemoths that want
to demonstrate that they truly grasp contemporary needs re. big and
broad data. (015)
> Following is a recent article "Whatever became of Watson?"
>> You are speaking about JSON syntax over RDFXML or Turtle. And by the way,
>> they are using HTML+Microdata, yet another format... (016)
Remember, Watson used LOD Cloud data, NLP, and machine learning. Take
one out of the aforementioned out of the mix and it wouldn't have happened. (017)
> There are several issues here:
> 1. Trade-offs in syntax for human readability, computer efficiency,
> and compactness in transmission and storage. JSON is better in
> all three categories. (018)
JSON is fine and rapidly being adopted re. Linked Data. I don't have any
issue with JSON. (019)
> 2. Interfaces to various languages and tools. RDF provides untyped
> triples, but JSON supports typed and untyped N-tuples.
> 3. Relation to web pages. RDF/XML was designed to be embedded anywhere
> multiple statements in a block. It requires tags such as RDFa
> or Microdata to link the blocks to web pages.
> My recommendation is to support everything, and let developers make
> their implementation choices on a case by case basis. Those choices
> should be decoupled from the logic and ontology. (020)
Yes, of course. That's my view point also. We shouldn't impose stuff on
>> The information and data space dimensions of the Web are the greatest
>> showcases for URIs.
> I agree. But those advantages came from the Internet address scheme
> plus HTML. (022)
> The additional features added by XML are useful, but the
> desire for HTML5 shows that most webmasters weren't thrilled with XML. (024)
XML is dying..... :-) (025)
>>> So the "meme" isn't new.
>> The meme is very new when you factor in:
>> 1. URIs
>> 2. Ubiquity of the World Wide Web.
> Both Vannevar Bush and Ted Nelson had "factored in" those ideas many
> decades ago. A quotation from VB's article "As We May Think":
>> Wholly new forms of encyclopedias will appear, ready made with a mesh
>> of associative trails running through them, ready to be dropped into
>> the memex and there amplified. The lawyer has at his touch the associated
>> opinions and decisions of his whole experience, and of the experience
>> of friends and authorities. The patent attorney has on call the millions
>> of issued patents, with familiar trails to every point of his client's
>> interest. The physician, puzzled by a patient's reactions, strikes the
>> trail established in studying an earlier similar case, and runs rapidly
>> through analogous case histories, with side references to the classics
>> for the pertinent anatomy and histology. ... The historian, with a vast
>> chronological account of a people, parallels it with a skip trail which
>> stops only on the salient items, and can follow at any time contemporary
>> trails which lead him all over civilization at a particular epoch. There
>> is a new profession of trail blazers, those who find delight in the task
>> of establishing useful trails through the enormous mass of the common record.
>> The inheritance from the master becomes, not only his additions to the
>> record, but for his disciples the entire scaffolding by which they were
> This sounds rather familiar today. But VB wrote it in 1947.
> 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
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen (029)
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)