RDF Interfaces - equality, entailment, problems

Ivan Herman wrote:
> On 24 Apr 2011, at 19:33, Nathan <nathan@webr3.org> wrote:
>> Shane McCarron wrote:
>>> On 4/24/2011 8:42 AM, Nathan wrote:
>>>> Also, just what do we do about literals people are creating? for example:
>>>>
>>>>  createLiteral(100, "xsd:double");
>>>>  createLiteral(10*10, "xsd:double");
>>>>  createLiteral(1e2, "xsd:double");
>>>>  createLiteral(+1e2, "xsd:double");
>>>>  createLiteral(+100, "xsd:double");
>>>>
>>>> All of those values are of the type (number) in javascript and have the same value "100" with no access to the original form.
>>> To my mind all those are the same.  There is nothing we *can* do.  If you want to put in a note to that effect, it might be reasonable.
>> Yes they are all the same, so I guess I'm saying that it feels a little strange to have:
>>
>>  createLiteral(100, "xsd:double").equals( createLiteral(+1e2, "xsd:double") ) === TRUE
>>
>> whilst if the original source was say turtle, then they would not be considered equal, seems like unexpected functionality to me.
>>
>> Back to reality, just what do we write in the RDF API specification?
>>
>> - keep it as is, which appears to work, afaict - compare value if you know the datatype, else compare lexical form
>>
>> - change to read something like "equality is defined by RDF <link> here"
> 
> This is the same discussion as before... We define an API to RDF. We should not define a different form of equality; instead, refer to the relevant RDF spec.

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

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.

Which brings me right back to my initial conclusion above.

Additionally, the same applies for every layer of API built on top of 
the RDF Interfaces as well, at no point could you work with language 
native types, because you just hit a or b again.

This leads on to the topic of entailment from rdf-mt, there is of course 
D-entailment, but then we're getting in to the realms of RDFS and 
interpretations, and this raises several other issues, such as 
inconsistencies, unknown datatypes, practical things like different 
entailment regimes from SPARQL and OWL, where to practically draw the 
line so things are in fact usable, requiring schema/ontology awareness 
when working with data and so forth.

Guidance? I'm at a bit of a loss here, the API really isn't very nice to 
work with when you don't have any language native types to work with, 
but I don't see how we can just naively map up common datatypes to value 
spaces without it creating unexpected functionality at some level, and 
I'm unsure whether we can get in to the full entailment, interpretation 
and semantics side of things in the API - I guess you can say I'm stuck. 
- Help!

Best,

Nathan

Received on Sunday, 1 May 2011 14:36:48 UTC