On 03/09/15 10:27, Stian Soiland-Reyes wrote:
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.
The parser() operations all default their arguments so you should be
able to call one only, maybe
parse(StreamRDF, uri, base, hintLang)
I should not need that Context object, right?
Correct - not needed. Context is only used to pass special arguments
specific to a parser impl (and I think there are none ATM). It defaults
to global anyway. More a writer thing.
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
I'll have to look harder but why are there special SparqlBnodes and
SparqlGraphs? An RDF graph is an RDF graph, a set of triples.
And different hashCode/equals :-)
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.
I don't see that as a problem. The result items need to be made by a
factory passed in. Add a Variable type and would something like this work?
SPARQLResultSet rs = performSelectQuery(url, queryString, factory)
Grapg g = performConstructQuery(url, queryString, factory)
(if we handle queries as strings, then either this explicit naming or
SPARQLResult as a container for a resultset, a graph or a boolean)
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 :)
