My requirement centres around a caching graph. For my requirements I know that I am interested in subjects of triples so I can cache based on the subject. Long story short.
When I query the RDFConnection for the second time I need the blank values to be the same as the first time so that I can properly update the cache. I do the updates with blanks in a cleaner manner where I always backtrack to a non-blank subject so I can build from that. Claude On Sun, Dec 17, 2017 at 3:38 PM, Andy Seaborne <[email protected]> wrote: > > > On 17/12/17 15:19, ajs6f 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? >> > > They already exist! > > 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. >>> >> > Claude - I have the same requirement, and was checking and working on it > only yesterday. > > What is the requirement and use case here? > > Mine is for update rdf-delta. > > (1) Pushing patches involving blank nodes (one way requirement) > (2) Searching the graph and sending changes based on bnodes (round trip > requirement). > > There are bits and pieces in different places and it could do with pulling > together. It's (they - there are two mechanisms) been around for a long > time and there are a few things to sort out as handling isn't consistent > ATM and a couple of code paths have been lost/not written. > > XML results works if setup up right. > > JSONInput on its own isn't sufficient. What did you enable in Fuseki? It > would be good to know what works already. > > BTW - this mode is dubious in terms of spec compliance. It also happens > to be very useful. > > Andy > > > >>> 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 >>> >> >> -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
