On 12/18/11 4:07 PM, John F. Sowa wrote:
> KI
>> > But that's no longer the case today. For instance, you have SPARQL
>> > which is closely aligned to SQL.
> The main similarity between SPARQL and SQL is the keyword SELECT.
> SPARQL only supports triples, it only supports a tiny subset of SQL,
> and using a path-based method to state a query is a royal pain. (01)
It depends on the implementation. Yes, by default path-based methods are
a pain, but they are surmountable. Basically, we support SPARQL (with
ability to integrate SQL), SPASQL (SPARQL inside SQL) and SQL. (02)
My point is that SPARQL can be implemented in different ways, which
we've demonstrated for years. The goal is getting to a "best of both
worlds" scenario which is now possible. (03)
SPARQL and SQL are both FOL based, as you know.
>
> They had path-based methods for DBMS in the 1970s, and programmers
> voted with their feet: SQL was much easier for them to use. (04)
Yes, but SQL is limited. In the 1970's you didn't have a ubiquitous Web
of (Linked) Data. Today we have data heterogeneity as part of the mix,
so those who walked with their feet now have context for "back sliding"
with those same pair of feet, so to speak [1] :-) (05)
> Most
> object-oriented DBs today support both SQL and path-based methods,
> and the majority of programmers prefer SQL. (06)
Methinks, for programmers that don't know any better re. SQL preference.
The combination is far more potent today. (07)
>
> KI
>> > Please forgive the past. Initially they got many things wrong,
>> > across a number of technical and marketing fronts, but that's the past
> Forgiveness is irrelevant. (08)
I mean, try to discount the flaws of the past when speaking about these
matters today. I say this because things have evolved. (09)
> The question is what do paying customers
> buy and use. As Guha said, "Somehow RDF never caught on." He's now
> working at Google, where they build Google apps around JSON, which
> supports n-tuples, including typed n-tuples -- you can map those
> equally well to a triple-store or to an RDBMS. (010)
Yes, of course. (011)
I am also saying none of that is mutually exclusive with regards to
items coming out of the Semantic Web Project, today. In the past, things
were broken and provincial, that isn't the case today though. (012)
>
> But customers are concerned about getting locked in to a single
> supplier. (013)
Sure, and they should be wary of this forever. (014)
> So Google, Microsoft, and Yahoo! founded schema.org. (015)
Hmm. they actually founded Schema.org with their search engines in mind.
Others from the Semantic Web community came on board with re., TBox
cross links to DBpedia, SIOC, FOAF, Dublin Core, etc.. that enhance
Schema.org while demonstrating to Guha and others that the original
vision could work, modulo preoccupation with a specific syntax. (016)
The biggest contribution of Schema.org was/is driving the final nail in
the coffin re. timeless distraction associated with syntax wars re.
Semantic Web vision. It took the marketing might of Google and others to
get the W3C to reevaluate a few critical things. (017)
Links: (018)
1. http://queue.acm.org/detail.cfm?id=1961297 -- A co-Relational Model
of Data for Large Shared Data Banks (019)
>
> John (020)
-- (021)
Regards, (022)
Kingsley Idehen
Founder& CEO
OpenLink Software
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 (023)
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
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 (01)
|