- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sat, 29 Nov 2008 13:58:02 -0500
- CC: "public-lod@w3.org" <public-lod@w3.org>
Danny Ayers wrote: > <%=profanity /%> > or something - cool thread > > while I disagree with many of Aldo's individual points, getting them > surfaced is really positive > > in response to a line from the firestarter: > > "The only reason anyone can afford to offer a SPARQL endpoint is because it > doesn't get used too much?" > > while my love of SPARQL is enormous, I can't see the SPARQL endpoint > being a lasting scenario. > But you seem to assume that SPARQL endpoints are the definitive scenario today? I see SPARQL endpoints as simply optional. The public visibility will be determined by needs and the wishes of a give Linked Data Space owner. Take DBpedia as an example, it works fine as a Linked Data Space on its own, but it also offers a SPARQL endpoint for those who want to speak SPARQL. As I've stated (already), the real issue comes down to deep DBMS level issues re. scalability and query processing prowess. Today, we don't have a ODBC or JDBC DSNs published on the Web primarily because the naming granularity isn't there (i.e. record level naming), single record access and manipulation has always been a problem for SQL, and there's never been a truly standardized data access mechanism that incorporates the networking layer. Linked Data picks up from where the RDBMS realm simply runs out of steam re. Open Data Access, but this doesn't mean that the techniques in the RDBMS realm can form the basis of a new kind of DBMS frontier of the kind I believe the Linked Data Web ultimately delivers. > linking and the fresh approach to caching this will demand, need > another rev. before the web starts doing data efficiently > When you say: "..Web doing data efficiently", what do you mean? Scalable and "change sensitive data access" on the Linked Data Web is fundamentally an issue for Linked Data Deployment platform player differentiation (imho). I think HTTP, RDF, and SPARQL (plus extensions) already provide ample building blocks for building solid platforms. We just have to remember that data access and DBMS technology predates the Web and lots of the techniques and knowledge from this realm are vital when it comes to scalability and efficiency challenges. In my eyes, and from my experience, the Web is only beginning to comprehend DBMS matters. And like most things relating to humans, some lessons are only learned the hard way :-) Kingsley > the answer to the quoted line is the question - how can you not > afford? Classic stuff re. amazon opening up their silo a little bit - > guess what, profit! > > pip, > Danny. > > > 2008/11/28 Juan Sequeda <juanfederico@gmail.com>: > >> >> On Thu, Nov 27, 2008 at 2:33 PM, Peter Ansell <ansell.peter@gmail.com> >> wrote: >> >>> 2008/11/27 Richard Cyganiak <richard@cyganiak.de> >>> >>>> Hugh, >>>> >>>> Here's what I think we will see in the area of RDF publishing in a few >>>> years: >>>> >>>> - those query capabilities are described in RDF and hence can be invoked >>>> by tools such as SQUIN/SemWebClient to answer certain queries efficiently >>>> >>> I still don't understand what SQUIN etc have that goes above >>> Jena/Sesame/SemWeb etc which can do this URI resolution with very little >>> programming knowledge in custom applications. >>> >> True, jena/sesame does everything that SQUIN entails to do. However, SQUIN >> is oriented to the "web2.0" developers. How is a php/ror web developer going >> to interact with the web of data and make some kind of semantic-linked data >> mashup over a night? SQUIN will let them do this. No need of having jena, >> learning jena, etc. Make it simple! If it is not simple, then developers are >> not going to use it. >> >> >> >> >> > > > > -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President & CEO OpenLink Software Web: http://www.openlinksw.com
Received on Saturday, 29 November 2008 18:58:38 UTC