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
