On 12/21/16 4:57 PM, Ruben Verborgh wrote: > Hi Kingsley, > >> The Semantic Web community hasn't focused exclusively on query execution >> speed. > Let me clarify myself: > the scientific SemWeb community mostly focused on speed, > as is apparent from publications about SPARQL query execution > (and, from personal experience, many researchers and reviewers > still having trouble to understand why speed is not our main focus).
Research papers and conference workshops have focused on these matters, for a variety of reasons. As I said, the driver for this focus in reality, is the 250 msec response time which is a key threshold for human attentions when working with solutions (on or offline). > >> Anyone that encounters a service (Web or Semantic Web) expects results >> in acceptable timeframes (typically <= 250ms) , that's a function of >> user behavior on the Web or anywhere else. > Yes, and it is my opinion that public SPARQL endpoints overpromise in that > regard. They don't. SPARQL endpoints exist, and experience varies. Ditto motivations behind the endpoints. > The whole public SPARQL endpoint discourse has made us believe > that it is actually realistic to have free+fast+high availability, > as is the case for any other Web service. There is no such thing as a free+fast+high availability solution that costs the solution provider $0.00. That simply doesn't exists!! > But given that SPARQL is more expressive per request > than any other Web service I know, this cannot hold. > > In simple terms: SPARQL is a very expressive > and hence very expensive API. > > In technical terms: show me any other API > that exposes a PSPACE-complete interface. SPARQL is a Query Language that includes an HTTP API accessible via SAPRQL Endpoints. What you are not accepting is the notion of queries that complete, in a configurable query completion timeframe. > >> You will find that Wikidata, is doing the very same thing, but with much >> more hardware at their disposal, since they have more funding than >> DBpedia, at this point in time. > Indeed. > >> Your "Simply doesn't work on the public Web" claim is subjective > Let me clarify "simply doesn't work": > companies/institutions that host their data in any other API on the Web > will see a substantial increase in server costs > when they try to host that same data as a public SPARQL HTTP service. Again subjective. You are implying that cost vs benefit analysis don't drive decisions to put services on the Web, of course they do. > My claim is that this increase is so substantial, > that SPARQL endpoints cannot become a reality on the public Web > at the same customer cost (= often free) of any other API on that same Web, > and hence will not become a reality. The costs are not prohibitive. This is where I utterly completely with you. > Concretely, for most institutions that want to make their data queryable for > free, > the SPARQL protocol will simply be too expensive for their budgets. Academic institutions, maybe. The rest of the world, it basic economics, value propositions, and business models. > Alternatives, like dumps, LD documents, TPF, might be feasible, > but they all come at another cost. > No silver bullet. Has anyone told you that SPARQL Endpoints are a silver bullet? Kingsley > > So far, that claim has not been proven wrong. > > Best, > > Ruben > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata -- Regards, Kingsley Idehen Founder & CEO OpenLink Software (Home Page: http://www.openlinksw.com) Weblogs (Blogs): Legacy Blog: http://www.openlinksw.com/blog/~kidehen/ Blogspot Blog: http://kidehen.blogspot.com Medium Blog: https://medium.com/@kidehen Profile Pages: Pinterest: https://www.pinterest.com/kidehen/ Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen Twitter: https://twitter.com/kidehen Google+: https://plus.google.com/+KingsleyIdehen/about LinkedIn: http://www.linkedin.com/in/kidehen Web Identities (WebID): Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
