Re: RDF Interfaces - equality, entailment, problems

On 01/05/11 18:56, Nathan wrote:
> Andy Seaborne wrote:
>>
>>> 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.
>
> Indeed, but to which string?

Canonical form, ideally, but any that the datatype would map to the 
value.  Your languages toString() is helpful.

>>> 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.
>
> Good point, unsure whether it would be good to have that don't know
> scenario incorporated, if the datatype isn't known then compare
> lexically seems like a valid option.

Open world.

On the (semantic) web, you need to be able to deal with unknown datatypes.

What must not happen is that sameValue says "no" when it could be "yes" 
(or the other way round) if you add more information to the system. 
sameValue being true or false is a promise, "don't know" can change to 
true or false given more information.

Ivan's message, which crossed mine, says it well:
"""
The Literal interface should store both the (original) lexical value and 
the value in data space
"""

	Andy

>
> Best,
>
> Nathan

	Andy

Received on Sunday, 1 May 2011 19:00:46 UTC