Hi Andy,
This analogy might help (or not):
>
> There is a table with 4 metal spheres on it in a line across it. Each
> sphere is exactly kind of material, the same mass, the same colour and the
> same shininess. You can ask "is that sphere the same as that other one?"
> by pointing to two of them. If you put them in a bag, shake the bag and
> take one out, you can't tell whether this chosen one is the same as the one
> that was on the right-hand end of the line.
>
How many Spheres will you be able to take out of the bag? I once made the
mistake (resulting in a bug) to assume identity of the indiscernible in
RDF, this is however not the case.
To have the sphere exist they need to be part of graph.
If this is the graph:
_:a p _:b.
_:b p _:c.
_:c p _:d.
_:d p _:e.
_:e p _:a.
We can put the 5 sphere to the bag and shake as much as we want we will
always have 5 spheres in the bag. Of course, as you say, if we take one out
we can say which one it is. (But we don't care, we are happy having a shiny
meta sphere in a circle with 4 other spheres).
By contrast if this is the graph:
_:a rdf:type ex:Sphere.
_:b rdf:type ex:Sphere.
_:c rdf:type ex:Sphere.
_:d rdf:type ex:Sphere.
_:e rdf:type ex:Sphere.
When we open the bag we might just have one sphere. Which is fine, as the
above graph evaluates to true in any world where there is at least one
sphere.
So far for what RDF is concerned. Things are a bit different for the API
that allows creating the graph, in this situation we might actually be
pointing (or looking) at spheres and as long as we do so they should not
disappear. After having added the above 5 triples we might go on adding:
_:a rdf:type ex:Shiny.
_:b rdf:type ex:Heavy.
_:c rdf:type ex:Radiactive.
_:d rdf:type ex:Transparent.
_:e rdf:type ex:Whole.
In this case we should have 5 spheres described by 10 triples. Every well
behaving quality bag will give as back all 5 spheres[*].
In other words as long as I am looking at the spheres I might go on adding
things to theirs descriptions making them actually distinct spheres.
This distinction between being looking at (or pointing at) spheres and just
having them in the bag is very straight forwardly (and imho elegantly)
modeled with the distinction of an object instance being reachable or not.
In the clerezza code and in the SVN commons proposal code along the
following lines will works as expected.
{a,b,c,d,e} is a set of 5 BlankNodes (i.e. we have 5 objects, no two of
them are equals).
g.add(a, RDF.type, EX.Sphere);
g.add(b, RDF.type, EX.Sphere);
g.add(c, RDF.type, EX.Sphere);
g.add(d, RDF.type, EX.Sphere);
g.add(e, RDF.type, EX.Sphere);
//if we save the graph here the backend might just store one triple
//but as long as wen can do the following
g.add(a, RDF.type, EX.Shiny);
g.add(b, RDF.type, EX.Heavy);
g.add(c, RDF.type, EX.Radiactive);
g.add(d, RDF.type, EX.Transparent);
g.add(e, RDF.type, EX.Whole);
//we will end up storing 10 triples
In the API proposal it is neither clear in which situations the backend
might remove redundant information (as new blanknodes object with the same
id might be created with the same factory) nor if the latter 5 add
invocations will indeed add triples with the same subject (as the
implementation might have created bnodes that differ from the original 5 as
these might originate from another graph, see my answer to Stian).
So basically I agree with everything you write in your email and don't see
any reason to expose the internal identifier in the API and have complex
identity criteria.
Cheers,
Reto
[*] Well, yeah the problem of the metaphors: we will always get back 5
bnodes, even though the graph also evaluates to true in a universe with
just one shiny, heavy, radiactive, transparent and whole sphere.
