Claude,
This commit (on my Jena working copy):
https://github.com/afs/jena/commit/5daab5fa2adf50140c35871ebeeee84df2ec3966
fixes up JSON results for you ... if Fuseki and client are run with the
right arguments.
fuseki-basic --set arq:outputGraphBNodeLabels=true .....
then
rsparql --results=json
--set arq:inputGraphBNodeLabels=true
--set arq:outputGraphBNodeLabels=true
--service http://localhost:3030/ds/query 'SELECT * { ?s ?p ?o}'
worked for me.
(XML results would be better as they don't need the commit but I can't
see to set the accept header that ATM. HttpQuery/QueryEngineHTTP don't
seem to allow a global change of default. Style conflict in usage or I
just didn't find it.)
Andy
On 17/12/17 20:13, Andy Seaborne wrote:
Are you seeing
{ "type": "bnode" , "value": "b0" }
for bytes on the wire?
If so, and this would explain your UUID comment, then note that "b0" is
not the internal blank node label. "b0" is result-document scoped. Both
the serializer and deserializer do blank node scoping by default.
That's why the blank node labels are short like b0, b1,
It would be
{ "type": "bnode" , "value": "c46a7fb56a6126a3d31a1250510b838f" }
if emitting blank node labels (that's a real example).
Parser-generated blank node ids are UUID-related.
The JSON writer has support via the system-wide context setting ...
which is useless because the reader does not support it ATM. XML
results do work but are not accessible via RDFConnection (I think -
might have to use HttpQuery).
Andy
On 17/12/17 17:53, Claude Warren wrote:
I am using the RDFConnectionFactory to create an RDFConnection to Fuseki.
The issue arises when the Connection deserializes the result from Fuseki.
Fuseki is returning the JSON format (I used no special settings for this,
it just works this way out of the box)
Using an RDFConnection to a local model, or dataset does not exhibit this
issue.
I traced my issue down to the JSON deserializer I mentioned above.
Claude
On Sun, Dec 17, 2017 at 3:19 PM, ajs6f <[email protected]> wrote:
Claude-- I'm looking at RDFConnection, but it's an interface. I think
you
mean around L220 of JSONInput itself, right?
It looks like SyntaxLabels has some LabelToNode factory methods that
might
fit the bill, like createNodeToLabelAsGiven(), but JSONInput doesn't
offer
any way to select which method to use. At L195 it uses SyntaxLabels.
createLabelToNode().
We could thread such a mapping choice all the way through the call
stack,
but that seems a bit difficult to me. Maybe we could introduce a Context
setting for this purpose?
ajs6f
On Dec 17, 2017, at 9:28 AM, Claude Warren <[email protected]> wrote:
Greetings,
I am looking at org.apache.jena.sparql.resultset.JSONInput and the way
in
which it parses blank nodes.
I have a requirement for an application such that the same blank node
returned on multiple queries returns the same blank node id.
I have verified that Fuseki does this (given that the data is only
loaded
once -- reloading the data can renumber the nodes). In any case Fuseki
seems to return the ids from the underlying data store.
However, when RDFConnection is executing a query it remaps the ids
during
the query.
Down around line 220 it uses a labelMap to construct a new value for
the
bnode. My question is:
Is there a simple way to have the LabelMap return the same value for
the
same blank node across multiple queries? (assuming the value does not
change in the data store).
I know there was a discussion of using UUIDs or some such to
generate the
blank ids on the way into the graph but I don't see any way for
RDFConnection to return them consistently.
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
