RDFConnection fetch() issue?

[Claude Warren <cl...@xenei.com>]

I am working with an RDFConnection to a Fuseki server.

The server is set up as

DatasetGraph serverdsg = DatasetGraphFactory.createTxnMem();
FusekiServer server = FusekiServer.make( 3030, "/ds", serverdsg );
        server.start();

I have called

ARQ.enableBlankNodeResultLabels(true);

It seems that  the fetch() and query() results for the same graph are
different.

calling

connection.query( "SELECT ?s ?p ?o  WHERE {  ?s ?p ?o }" )

yields different blank node ID from

connection.fetch();

and

connection.queryConstruct( "CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }" );

yields a different blank nodes from either of the above.


I'm not sure if this is a defect or an undocumented feature, or perhaps a
bit of both.

I can understand that the "fetch" is different as is simply gets a TURTLE
dump of the db and so the blank nodes might be renumbered.  But I would
expect that the construct should return the same node values -- then again,
perhaps not as it is a new model as well.

If this is not a bug (and I am beginning to suspect it isn't) I think the
javadoc should be updated to specify when the
ARQ.enableBlankNodeResultLabels(true); is in play and when it is not.

Claude


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: RDFConnection fetch() issue?

[Andy Seaborne <an...@apache.org>]

On 20/01/18 23:51, Claude Warren wrote:
> I am working with an RDFConnection to a Fuseki server.
> 
> The server is set up as
> 
> DatasetGraph serverdsg = DatasetGraphFactory.createTxnMem();
> FusekiServer server = FusekiServer.make( 3030, "/ds", serverdsg );
>          server.start();
> 
> I have called
> 
> ARQ.enableBlankNodeResultLabels(true);
> 
> It seems that  the fetch() and query() results for the same graph are
> different.
> 
> calling
> 
> connection.query( "SELECT ?s ?p ?o  WHERE {  ?s ?p ?o }" )
> 
> yields different blank node ID from
> 
> connection.fetch();
> 
> and
> 
> connection.queryConstruct( "CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }" );
> 
> yields a different blank nodes from either of the above.

For the latter two, every call returns new blank nodes.

> 
> 
> I'm not sure if this is a defect or an undocumented feature, or perhaps a
> bit of both.
> 
> I can understand that the "fetch" is different as is simply gets a TURTLE
> dump of the db and so the blank nodes might be renumbered.  But I would
> expect that the construct should return the same node values -- then again,
> perhaps not as it is a new model as well.
> 
> If this is not a bug (and I am beginning to suspect it isn't) I think the
> javadoc should be updated to specify when the
> ARQ.enableBlankNodeResultLabels(true); is in play and when it is not.

Correct - this is not a bug.  "Result" here means ResultSet.

Adding round-trip handling to models without skolemization (which 
changes the RDF itself) would have to be done in parallel to result 
sets.  It is more work because there are more syntax combinations to 
consider.

Mapping labels happens twice: once on the way out (writing) to get 
either sort forms like "[:p 123 ; :q 456]" or nice labels _:b0, _:b1, 
and once on the way in, parsing the input.  Note the "[]" case make 
providing blank node labels have a major effect in appearance.

Exposing the iterator versions for CONSTRUCT is possible and non-standard.

For working with remote locations, when you want to round-trip blank 
node labels, and remain with formats that still legal standards,
is best restricted to result sets, failing a full, and non-standard,
log protocol (and ideally binary).  RDF Patch.

     Andy



> 
> Claude
> 
>