On 02/02/12 16:27, Martynas Jusevicius wrote:
Hey Andy,
may I be so bold as to suggest that Jena should drop its various
methods of HTTP access and use one specialized framework to do that
job?
Since RDF and LinkedData are very much RESTful applications, a RESTful
framework like JAX-RS [1] would be more suitable than low-level
libraries like HTTP Commons etc.
Jersey (main Java implementation of JAX-RS) provides nice classes like
WebResource [2] with uniform HTTP interfaces and builder methods.
Using it, I was able to implement loadModel(filenameOrUri) much more
concisely:
public Model loadModel(String filenameOrURI)
{
ClientConfig config = new DefaultClientConfig();
config.getClasses().add(ModelProvider.class);
return Client.create(config).
resource(filenameOrURI).
header("Accept", getAcceptHeader()).
get(Model.class);
}
The new Apache HttpClient release (4.2. beta) has a fluent API. The
documentation does not appear to be on the website yet (the GA
documentation is), but it's in the download.
Andy
ModelProvider [3] abstracts the dirty job of reading Model from
request/writing Model to response and does it behind the scenes.
I was planning to use Jena's intefaces with JAX-RS implementations for
Linked Data access in DataManager [4], but now I can see that it's
much easier and uniform to do the way around.
I'm sure JAX-RS could also be useful in Fuseki etc.
Martynas
graphity.org
[1] http://jcp.org/en/jsr/detail?id=311
[2]
http://jersey.java.net/nonav/apidocs/1.5/jersey/com/sun/jersey/api/client/WebResource.html
[3]
https://github.com/Graphity/graphity-analytics/blob/rdf_editor/src/main/java/org/graphity/provider/ModelProvider.java
[4]
https://github.com/Graphity/graphity-analytics/blob/rdf_editor/src/main/java/org/graphity/util/DataManager.java
On Sun, Jan 29, 2012 at 6:53 PM, Andy Seaborne<[email protected]> wrote:
On 27/01/12 20:29, Martynas Jusevicius wrote:
Ok, that clears some things up.
So is there a good class to extend, like JenaReader?
Or should I start from scratch and implement RDFReader?
I think most mainstream Linked Data publishing methods should be
supported, at least these:
http://linkeddatabook.com/editions/1.0/#htoc65
Maybe the implementation could be broken into several levels that
extend each other:
a) content negotiation only
b) heuristics (like using file extension) not involving content-sniffing
c) GRDDL
d) HTML-sniffing to find<link>s etc
Martynas
That's a good breakdown. The (a)+(b) is the area I've been wanting to sort
out for some time if only to make adding parser types a bit more straight
forward. RDFa, microX, JSON-LD, native-to-triple generators, ... and
definitely not a fixed set.
As a contribution to this discussion for (a)+(b) I've gathered together
various bits and pieces into a experimental design:
http://s.apache.org/wbZ
I don't have a sense of how to incorporate (c)+(d) and hope you have ideas
here.
The idea is that reading/parsing is orthogonal to a model. In Jena2, there
is the possibility of per-model choice of reader implementation. I'm not
sure if any use is made of this feature. RDFReaderFImpl is the only
implementation active in Jena. Are there any others?
There is a need to configure the parsing process per-read, that is mainly
for RDF/XML as described at:
http://s.apache.org/BMB
which is all done with property settings.
We can separate reading from model. The FileManager already does this with
readModel(model, ...).
We can have a factory-style design with a function (static method):
read(Model m, String uri, String hintLang, Context context)
or rather:
read(Sink<Triple> destination, String uri, String hintLang, Context context)
where:
Sink<Triple> destination
where to send triples generated by the parser. There is a standard
wrapper for a graph that turns Sink.send into Graph.add.
String uri
The place to read.
String hintLang
A hint to the system of the syntax.
Context context
A set of property-values to configure the parser.
The process is :
open -> TypeStream
process -- choose parser, call parser
ts.close
"open" can use a FileManager to look in a list of places for the "uri"
(actually, a general label - maybe in the filing system, a Java resources,
zip file, on the web, servlet context, in a cache, ...). A nice feature of
the file manager is you can turn off locations - e.g. don't put a file
system component and the local file system isn't accessible which is good
for servers.
Andy
