Mark Diggory wrote: > On Feb 7, 2008, at 4:44 PM, David Huynh wrote: > > >> The JSONP protocol will be pretty specific to Backstage. If there's a >> desire to load data through SPARQL query, the right place to hook in >> would be between the server-side code of Backstage and the SPARQL end >> point. Right now server-side Backstage formulates its queries to the >> triple store by putting together Sesame "query algebra trees". If >> SPARQL >> is as expressive as Sesame's query algebra (supporting GROUP, COUNT, >> MIN, MAX), then it shouldn't be hard to swap in a SPARQL end point. >> > > If I recall correctly, Longwell itself doesn't use SPARQL queries > right now as thats a recent addition to Sesame. It doesn't sound like > your work is that far removed from the way that Longwell initializes a > Sesame memory or native store off a source of RDF data. > > Although a tangent... I thought it would be a great idea to expose the > SPARQL engine of the Sesame instance in Longwell as an endpoint. This > would allow for a rather powerful and flexible exposure of a DSpace > instances content within the semantic web. On top of this, if > services can be implemented on top of that engine, then they can be > much more encapsulated and reusable, for instance a mapping between > SRU/CQL and SPARQL and/or OAI and SPARQL would provide a the sysadmin > greater configurability over how content is represented in those > interfaces. > Yes, exposing a SPARQL end point would be trivial as we use Sesame underneath. For a fixed, large data set, that would be a conventional thing to do. For dynamic data sets, that's kinda fun: you "rent" a triple store just to do SPARQL on data at some URL.
David _______________________________________________ General mailing list General@simile.mit.edu http://simile.mit.edu/mailman/listinfo/general
