Sesame already has the concept of a HttpRepository if memory serves so this should be possible to do with relatively little work and as Andy points out this would give you guys the benefit of being able to support a wide range of stores.
Obviously some features may need to be implemented in a generic way because you won't necessary know the specific capabilities of the underlying store but that may in some sense be a good thing forcing you to think carefully about how to modularize and how to implement features by proxy/wrappers as necessary Rob On 10/5/13 10:47 AM, "Andy Seaborne" <[email protected]> wrote: >On 04/10/13 21:38, Peter Ansell wrote: >> From memory I think it is a Repository wrapper but I haven't looked at >>it for a while. >> >> I am on mobile only for the next week but I think the following is the >>url: >> >> https://github.com/ansell/jenasesame > >Forked from https://github.com/afs/JenaSesame (the file name AFS.txt is >a bit of a give away!) > >I hadn't done the Sesame API over Jena storge, only the other way round; >Jena API over Sesame storage. It's not a project I'm working on. > >IMO A better way would be to modularize the backends with SPARQL over >HTTP or over an API. . Then you can use a wide range of backends >without needing customization for each (HHTP) or little customization >(API). A tiered architecture, using SPARQL/HTTP for the conenction to >the database layer. > > Andy > > >> >> -- >> Peter >> >> On 05/10/2013, at 12:06 AM, Sergio Fernández >><[email protected]> wrote: >> >>> That refresh me the question (which maybe Andy or Peter could answer): >>>is there any Sesame Sail implementation for Jena? >>> Add a Jena TDB backend would be cool! >
