- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Thu, 10 Oct 2002 11:14:27 +0300
- To: "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, "Brian McBride" <bwm@hplb.hpl.hp.com>
- Cc: "RDF Core" <w3c-rdfcore-wg@w3.org>
[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]
> Node a = Node.createLiteral("foo");
> Node b = Node.createLiteral("foo");
> if ( a.equals(b) ) {
> System.err.println("a = b");
> }
> ...
>
> would print out
>
> a = b
> a is the object of t
It seems to me that the problem is in the Node equals()
method, as it is incorrectly presuming that string
equality of labels for any arbitrary node is the same
as semantic equality. For untidy inlined literals, this
is not the case, so the method would need to be modified
so that in fact a != b in the above example.
After all, a and b are Node objects, not strings, and one
would expect the Node comparison methods to reflect the
RDF MT, right?
My motivation for the earlier proposals of using systemID
prefixes on inlined literals to implicitly denote the
datatype was so that methods such as Node equals would not
have to change and one would be able to fairly presume that
label string equality is the same as semantic equality.
Thus, if
Node a = Node.createLiteral("foo");
Node b = Node.createLiteral("foo");
actually resulted in the nodes having the internal labels of
_:x"foo" and _:y"foo" then the existing implementation of
the equals() method based on simple string-equality of labels
would function as expected and conclude a != b as it should.
Still, simply fixing the Node comparison functions in Jena to
take into account that non-explicitly typed inlined literals
are not semantically equivalent even if string-equal would
do the job, eh?
Patrick
Received on Thursday, 10 October 2002 04:24:17 UTC