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. -Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
