Ross, I think you are not alone, as per this: http://howfuckedismydatabase.com/nosql/ kc On 11/6/13 8:54 AM, Ross Singer wrote: > 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 <[log in to unmask]> 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 <[log in to unmask]> >>> 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 <[log in to unmask]> 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 <[log in to unmask]> >>>>> >>>> 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 < >>>>>> [log in to unmask]> wrote: >>>>>> >>>>>> But the >>>>>>> question to every piece of meta data is *authority*, which is the part >>>>>>> of RDF that sucks. >>>>>>> >> -- >> Karen Coyle >> [log in to unmask] http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet >> -- Karen Coyle [log in to unmask] http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet