It might be that the Graph needs a method to look up blank nodes by some measure, without having to query for a big graph pattern of what was just inserted.
So now if you do String s = blankNode.internalIdentifier(); graph.add(blankNode, p, blankNode) and look it up again - than do I understand the contract correctly in that Graph is not required to return the same internalIdentifier()? If I get those BlankNodes out again - are they still .equal() to the inserted blankNode? On 31 March 2015 at 10:52, Andy Seaborne <[email protected]> wrote: > On 30/03/15 23:10, Peter Ansell wrote: >> >> All of the BlankNode's in the Triple that was added may be internally >> remapped during the add operation. Hence, the .equals will change when >> the remapping occurs. Returning the mapped values enables a user to >> get access to that information. >> >> Removing the return value is fine with me if it can't be supported in >> a performant way. It just removes the simple way for a user to know >> what BlankNode remapping occurred. > > > Peter, > > Great - and I see the change in git. > > A simpler example would have been a parser not wanting to use the return > from add() and an implementation that does not store Triple objects, but has > data structures using the subject/predicate/object directly. Returned > triples are just object churn albeit probably quite efficient churn. > > (hmm - interesting - so once mapped, the mapping is stable.) > > Andy > > >> >> On 31 March 2015 at 06:46, Andy Seaborne <[email protected]> wrote: >>>> >>>> - void add(Triple triple); >>>> + Triple add(Triple triple); >>> >>> >>> Returning something from add() does not work for me. >>> >>> (And even if it did, I would have expected "boolean" as to whether the >>> triple was actually added or not.) >>> >>> 1/ I don't understand "possibly mapping" being in the API. A triple is a >>> triple. What is the client supposed to do differently with .equals one >>> returned (it is .equals?) >>> >>> 2/ I am finding that having a flow back from add operations difficult to >>> deal with. >>> >>> A sequence of add(Triple) can be batched up and only need to be performed >>> before another operation is called that can observe the change. >>> >>> In the case a remote destination, the overhead per add is significant >>> (network rounds). But if it is delayed, then the return of anything is >>> not >>> available. >>> >>> For a general interface, this should be >>> >>> void add(Triple) >>> >>> Andy >>> >>> > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
