Ethan, thanks, it's good to have examples. I'd say that for "simple linking" SPARQL may not be necessary, perhaps should be avoided, but IF you need something ELSE, say a query WHERE you have conditions, THEN you may find that a query language is needed. kc On 11/6/13 9:14 AM, Ethan Gruber wrote: > I think that the answer to #1 is that if you want or expect people to use > your endpoint that you should document how it works: the ontologies, the > models, and a variety of example SPARQL queries, ranging from simple to > complex. The British Museum's SPARQL endpoint ( > http://collection.britishmuseum.org/sparql) is highly touted, but how many > people actually use it? I understand your point about SPARQL being too > complicated for an API interface, but the best examples of services built > on SPARQL are probably the ones you don't even realize are built on SPARQL > (e.g., http://numismatics.org/ocre/id/ric.1%282%29.aug.4A#mapTab). So on > one hand, perhaps only the most dedicated and hardcore researchers will > venture to construct SPARQL queries for your endpoint, but on the other, > you can build some pretty visualizations based on SPARQL queries conducted > in the background from the user's interaction with a simple html/javascript > based interface. > > Ethan > > > On Wed, Nov 6, 2013 at 11:54 AM, Ross Singer <[log in to unmask]> 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