Hey Karen, It's purely anecdotal (albeit anecdotes borne from working at a company that offered, and has since abandoned, a sparql-based triple store service), but I just don't see the interest in arbitrary SPARQL queries against remote datasets that I do against linking to (and grabbing) known items. I think there are multiple reasons for this:
1) Unless you're already familiar with the dataset behind the SPARQL endpoint, where do you even start with constructing useful queries? 2) SPARQL as a query language is a combination of being too powerful and completely useless in practice: query timeouts are commonplace, endpoints don't support all of 1.1, etc. And, going back to point #1, it's hard to know how to optimize your queries unless you are already pretty familiar with the data 3) SPARQL is a flawed "API interface" from the get-go (IMHO) for the same reason we don't offer a public SQL interface to our RDBMSes Which isn't to say it doesn't have its uses or applications. I just think that in most cases domain/service-specific APIs (be they RESTful, based on the Linked Data API [0], whatever) will likely be favored over generic SPARQL endpoints. Are n+1 different APIs ideal? I am pretty sure the answer is "no", but that's the future I foresee, personally. -Ross. 0. https://code.google.com/p/linked-data-api/wiki/Specification On Wed, Nov 6, 2013 at 11:28 AM, Karen Coyle <li...@kcoyle.net> wrote: > Ross, I agree with your statement that data doesn't have to be "RDF all > the way down", etc. But I'd like to hear more about why you think SPARQL > availability has less value, and if you see an alternative to SPARQL for > querying. > > kc > > > > On 11/6/13 8:11 AM, Ross Singer wrote: > >> Hugh, I don't think you're in the weeds with your question (and, while I >> think that named graphs can provide a solution to your particular problem, >> that doesn't necessarily mean that it doesn't raise more questions or >> potentially more frustrations down the line - like any new power, it can >> be >> used for good or evil and the difference might not be obvious at first). >> >> My question for you, however, is why are you using a triple store for >> this? >> That is, why bother with the broad and general model in what I assume >> is a >> closed world assumption in your application? >> >> We don't generally use XML databases (Marklogic being a notable >> exception), >> or MARC databases, or <insert your transmission format of choice>-specific >> databases because usually transmission formats are designed to account for >> lots and lots of variations and maximum flexibility, which generally is >> the >> opposite of the modeling that goes into a specific app. >> >> I think there's a world of difference between modeling your data so it can >> be represented in RDF (and, possibly, available via SPARQL, but I think >> there is *far* less value there) and committing to RDF all the way down. >> RDF is a generalization so multiple parties can agree on what data >> means, >> but I would have a hard time swallowing the argument that domain-specific >> data must be RDF-native. >> >> -Ross. >> >> >> On Wed, Nov 6, 2013 at 10:52 AM, Hugh Cayless <philomou...@gmail.com> >> wrote: >> >> Does that work right down to the level of the individual triple though? >>> If >>> a large percentage of my triples are each in their own individual graphs, >>> won't that be chaos? I really don't know the answer, it's not a >>> rhetorical >>> question! >>> >>> Hugh >>> >>> On Nov 6, 2013, at 10:40 , Robert Sanderson <azarot...@gmail.com> wrote: >>> >>> Named Graphs are the way to solve the issue you bring up in that post, >>>> in >>>> my opinion. You mint an identifier for the graph, and associate the >>>> provenance and other information with that. This then gets ingested as >>>> >>> the >>> >>>> 4th URI into a quad store, so you don't lose the provenance information. >>>> >>>> In JSON-LD: >>>> { >>>> "@id" : "uri-for-graph", >>>> "dcterms:creator" : "uri-for-hugh", >>>> "@graph" : [ >>>> // ... triples go here ... >>>> ] >>>> } >>>> >>>> Rob >>>> >>>> >>>> >>>> On Wed, Nov 6, 2013 at 7:42 AM, Hugh Cayless <philomou...@gmail.com> >>>> >>> wrote: >>> >>>> I wrote about this a few months back at >>>>> >>>>> http://blogs.library.duke.edu/dcthree/2013/07/27/the- >>> trouble-with-triples/ >>> >>>> I'd be very interested to hear what the smart folks here think! >>>>> >>>>> Hugh >>>>> >>>>> On Nov 5, 2013, at 18:28 , Alexander Johannesen < >>>>> alexander.johanne...@gmail.com> wrote: >>>>> >>>>> But the >>>>>> question to every piece of meta data is *authority*, which is the part >>>>>> of RDF that sucks. >>>>>> >>>>> > -- > Karen Coyle > kco...@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet >