On Fri, Jan 16, 2015 at 12:29 AM, Peter Ansell <ansell.pe...@gmail.com> wrote:
> The only sticking point then and now IMO is the purely academic > distinction of opening up internal labels for blank nodes versus not > opening it up at all. Reto is against having the API allow access to > the identifiers on academic grounds, where other systems pragmatically > allow it with heavily worded javadoc contracts about their limited > usefulness, per the RDF specifications: > Hi Peter, Sorry for the late reply. I see that the javadoc for the internalIdentifier method has now become quite long. It says: * In particular, the existence of two objects of type {@link BlankNode} * with the same value returned from {@link #internalIdentifier()} are not * equivalent unless they are known to have been created in the same local * scope. It is however not so clear what such a local scope is. It says that such a local scope may be for example a JVM instance. Can the scope also be narrower? To allow removing redundancies (as described in https://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/README.md) no promise should be made that a bnode with the same ID in the same JVM will denote the same node. On the other hand, how long is it guaranteed thath if I have a BNode objects I can add triples to a graph and this object will keep representing the same RDF Node? Does it make a difference if I keep the instance or is I create a new instance with the same internal identifier? Similarly: can I add bnodes I get form one graph form one implementation to another? If I get BNode :foo from G1 can I add the triple (:foo ex:p ex:o) it to G2? When later or I will add (:foo ex:q ex:r) to G2 will the two triples have the same subject? I think these are important questions to allow generic interoperable implementations. I'm not saying that questions like the one I answer in the Readme of my draft cannot be satisfactory answered when having such an internal identifier, but I think it might get more complicated and less intuitive for the user. Also, you're writing about "opening up" the labels. This make sense from a triple store perspective where the BNode have such an internal label. However I think this should not be the only usecase scenario. One can very well use the RDF API to expose some arbitrary java (data) objects as RDF. I've illustrated such a scenario here: http://mail-archives.apache.org/mod_mbox/stanbol-dev/201211.mbox/%3CCALvhUEUfOd-mLBh-=xkwblajhbcboe963hdxv6g0jhnpj6c...@mail.gmail.com%3E I'm not sure if with the github API one could say "the scope is the node instance" and return a fixed identifier for all BNode. If so the identifier is obviously pointless. If on the other hand one would have to assign identifier to all the objects the complexity of the implementation this would make implementations more complex both in terms of code as in terms of memory usage. Again, it seems to make things more complex while I see no clear advantage comparing with the toString() method the object has anyway. Cheers, Reto