> On Feb 15, 2017, at 4:31 PM, Andy Seaborne <[email protected]> wrote: > On 14/02/17 15:52, A. Soroka wrote: <snipped> >> [Fedora Commons] does offer a lot more, but it might still be scoped enough >> and quickly scalable enough for your immediate needs. Obviously, even though >> I commit for it, it doesn't do all my LDP needs because I am here talking >> about doing another impl! :) > > What needs do you see here?
It's more that as Osma noticed, Fedora does a great deal that isn't of use or interest to everyone. Within that project I tried to move forward an API specification that would allow for alternative (more minimal) implementations, but until that comes to fruition, it would be nice to have something available that is much, much lighter-weight and SPARQL-equipped out of the box and supported by a lively community (e.g. this one! :grin:). > The main choice is designing the URL space - making a SPARQL endpoint not > look like an LDP resource. You could snoop deeper into the request iof you > want namespace overlap. That may happen automatically as direct-named GSP > resources. But there again, it may be too clever and no GSP configured and > use JAX-RS be a lot easier to build. One question is whether there is a one-to-one dataset <=> LDP service matching. I'm not sure that has to be the case, or even should be. > Can LDP-NR be handled by web server static resource handling (and maybe a > filter if you want to chnage the HTTP header)? Something like that. I was also thinking about bringing something like Apache Camel for that purpose because you might have a lot of different sources for bitstreams. From Jena's POV, I think we can just leave that up to the integrator, yes? --- A. Soroka The University of Virginia Library
