On 14/02/17 15:52, A. Soroka wrote:
On Feb 14, 2017, at 10:42 AM, Osma Suominen
<[email protected]> wrote: 14.02.2017, 17:03, A. Soroka
kirjoitti:
Osma, you might want to take a look at Fedora Commons:
http://fedorarepository.org/
which is actually the project through which I came to work on
Jena. It might be a good option for you.
Thanks for the tip. It was on my radar, but seemed to have a
different focus than what I was looking for, far more than just a
LDP triple store. I will take a closer look!
It 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?
The biggest qualm I have about an LDP implementation for Jena is
that many people may want to store opaque bitstream resources
(what LDP calls LDP-NR, "non-RDF" resources) in their LDP
instance. That seems outside the bounds for Jena.
Right, that's not really Jena. However, a RDF-only LDP
implementation would, IMHO, make sense and could probably still be
very useful.
Well, we have pretty almost all the parts in place. Andy, do you
think this would make sense as a kind of "extension" for Fuseki or
better as an independent component? I'm inclined to the latter, in
hopes that a lot of the HTTP machinery could be handled very simply
by an off-the-shelf JAX-RS library, and I am already familiar with
JAX-RS, whereas Fuseki's HTTP machinery is a bit opaque to me at the
moment.
JAX-RS for the LDP side makes sense. The URL patterns can be fixed.
Fuseki deals with changes of the URLs served as it's running because
datasets get created in the UI and it works as a servlet filter to spot
request to a dataset, then directs requests to a single servlet to
execute all requests.
The filter looks in a registry to see if a request URL matches a
registered datasets eslse it falls though to static servlets (the admin
operations) and static page handling.
Fuseki request are all handled by one servlet. It happens to route to
other servlets which means some other system can pick-and-choose which
SPARQL features to provide. The actually operations are
semi-independent of servet-ness in case the core engine were to be used
in a non_HTTP context.
Embedded Fuseki routes "/*" to the filter.
All the stuff about "HttpAction" is to have a tracking object passed
tough requests. It was a good choice of design opattern.. Servlet
attributes would be much too low level building block and have no
structure specific to the usage.
So adding that to the JAX-RS dispatch for LDP should be an easy (!) to
add SPARQL over the LDP resources.
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. Can LDP-NR be
handled by web server static resource handling (and maybe a filter if
you want to chnage the HTTP header)?
Andy
--- A. Soroka The University of Virginia Library
