On 3 September 2015 at 09:47, Andy Seaborne <[email protected]> wrote:
> You can use RDFDataMgr.parse to invoke parsers - that way you get the > content negotiation and URL handling that already exists. Thanks, that should be easier. Then I can dispatch on source and not have to do my own input stream. While I can then remove lots of the URL/type code, I still need to do similar kind of branching to do the correct dispatching and null arguments. I should not need that Context object, right? > If the Parser interface (ParserBuilder? It's a builder pattern?) wraps Yes, builder pattern.. except you never get a separate Parser in the end.. perhaps you could? It would add another .build() step. Now you can parse at any step as soon as you have set a source. (and setting another source overrides the other ones rather than causing an error..) > On the quads/triple issue - Jena parses a dataset into a graph by only > passing through the default graph (StreamRDFLib.graph => ParserOutputGraph) OK, I agree this is a better approach. > 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? Yes, we also had the remote SPARQL implementation in clerezza-rdf-core by Reto, my patch of that to make it somewhat work with the Commons RDF base was here: https://github.com/stain/clerezza-rdf-core/tree/github-sql ResultSet as-is is tricky as it would just have variables and you would not know what graph to construct on the receiving end without a deep understanding of the query. Used with CONSTRUCT or DESCRIBE it's possible > 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. OK, good to know I am on the right track :) -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
