Stian,
You can use RDFDataMgr.parse to invoke parsers - that way you get the
content negotiation and URL handling that already exists. The
ReaderRIOT interface is the other end - the interface needed by parsing
code to fit into the find-and-connect framework.
[1]
public static void parse(RDFTermFactory rft) {
Graph graph = rft.createGraph() ;
StreamRDF dest = JenaCommonsRDF.streamJenaToCommonsRDF(rft, graph) ;
RDFDataMgr.parse(dest, "D.ttl") ;
graph.getTriples().forEach(System.out::println) ;
}
If the Parser interface (ParserBuilder? It's a builder pattern?) wraps
public static void parse(StreamRDF sink, String uri, String base, Lang
hintLang)
then I think there'll be less implementation code.
On the quads/triple issue - Jena parses a dataset into a graph by only
passing through the default graph (StreamRDFLib.graph => ParserOutputGraph)
Bigger question: there was an enquiry on users@jena about SPARQL and
CommonsRDF. Would ResultSet be a good next target? for parsing result
sets from remote places?
The common problem here is exposing engines (RDF parsers, writers,
result set parsers+writer(?)) in a common design style. As in your
design, the builder pattern looks like it has the right characteristics.
Andy
[1]
https://github.com/afs/commonsrdf-jena/blob/master/src/main/java/org/apache/jena/commonsrdf/examples/Ex_ParseIntoCommonsRDFGraph.java
On 03/09/15 02:07, Stian Soiland-Reyes wrote:
I am not sure if we should be saying anything about RDF parser and
writer interfaces.
Anyhow, I still felt a need to parse generic RDF files with Commons
RDF, and Apache Jena RIOT has a great collection of RDF parsers, so I
wrote a quick binding to see how it can generate and populate
arbitrary Commons RDF Graphs:
https://github.com/stain/commonsrdf-parser-jena
This works with a configurable Graph and RDFTermFactory implementation
together with Jena's StreamRDF - so no intermediate Jena graphs would
be in existence during parsing.
I was playing a bit with what kind of interface parsing would look
like - and ended up with a Factory pattern:
Parser parser = new JenaParser();
Path filePath = Paths.get("/tmp/file.rdf");
Graph g = parser.contentType(Parser.RDFXML).path(examplePath).parse();
This way you don't need to have multiple parse() methods, and can
support many of the optionals easily, e.g. base or content type. As
even the source is a method, then if path(), url() or inputStream() is
not appropriate for you, you can add a fourth source type by
extension.
A similar interface for writing could be made, but I didn't get too far.
Note that this is not Jena's Commons RDF implementation
https://issues.apache.org/jira/browse/JENA-1015
