When is equal and when is it nonequal (eg, the IRI interface)

I gave some thought on what it would mean to implement the API on top of my current tool and on top of RDFLib. I did run into an implementation problem that shows that the API implementation may not be very simple on top of an existing RDF environment and we may have to make some points to be specified a bit better. The question is: when are, say, instances of the IRI interface equal and when are they not equal?

The problem is as follows. In a package like RDFLib, the equality is fairly simple, it is based on the equality of the URIs (let us put, for a moment, the issue of IRI vs URI and its encoding aside). However, our version of the IRI has two attributes: the 'value' and the 'origin'. Ie, to IRI instances that have the same value but different origins are different.

But that may lead to strange things. Consider:

<div about="a:b" property="p:p" resource="q:q">bla bla</div>
<div about="a:b" property="p:p" resource="q:q">bla bla something else</div>

The generated RDF is

a:b p:p q:q .

because RDF is a _set_ of triples. But what will be the value of, say, store.size in the API? Is it '1' or is '2'? It looks as if in our current spec the value will be '2' because the origin values are different. But this is in contradiction with what the generated RDF is. That has then an effect on, say, the behaviour of the forEach method of the store, etc,...

There may be a simple solution if one implements the whole interface from bottom up. But that makes implementing this API on top of, say, RDFLib, fairly complex... In any case, this issue has to be clearly specified somewhere.


Ivan

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf