Re: RDF Interfaces - equality, entailment, problems

> Hi Ivan,
>
> I've been implementing the RDF Interfaces over the last couple of days,
> and have to admit that I'm struggling with the lexical-equality.
>
> Essentially it's increasingly looking like we'll need to drop all the
> typed literal conversion, and constrain the definition of createLiteral
> to be:
>
> createLiteral(DOMString value, DOMString language, NamedNode datatype)
>
> Which is very sad. Before this equality issue came up the API was quite
> nice to use, you could do createLiteral(10.3) and that would
> automatically create the appropriately typed Literal.
>
> A key problem is that if a graph is created from a serialization which
> contains the following:
>
> <a> <b> "100"^^xsd:double .
> <a> <b> "1E2"^^xsd:double .
> <a> <b> "1e2"^^xsd:double .
> <a> <b> "+100"^^xsd:double .
> <a> <b> "+1E2"^^xsd:double .
> <a> <b> "+1e2"^^xsd:double .
>
> and somebody creates a Literal with the code createLiteral(100,
> "xsd:double"), then:
>
> a) there is no lexical representation to compare against for equality

Convert the number to a string.

> b) if equality is done on value space, then it is equal to all those
> terms already in the graph, and further, all those terms are considered
> equal by the API so the graph would only contain one triple.

You may wish to have 2 notions: "sameTerm" and "sameValue"

sameTerm is equality at the level of same lexical form/language/datatype/

sameValue requires

In an open systems, sameValue may conclude "don't know", not just true 
and false.

For example:

samevalue("iiii"^^my:roman, "IV"^^my:roman)

Does the system understand my:roman?

If not, then while same lexical/same datatype means true even for 
unknown datatypes, here the lexical forms are different hence "don't know"

If it does understand my:roman, then it can conclude true.

	Andy

Received on Sunday, 1 May 2011 17:39:37 UTC