- From: Jonathan Rees <jar@creativecommons.org>
- Date: Wed, 3 Jun 2009 10:33:14 -0400
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: Axel Polleres <axel.polleres@deri.org>, "Peter F.Patel-Schneider" <pfps@research.bell-labs.com>, sandro@w3.org, public-rdf-text@w3.org
On Tue, Jun 2, 2009 at 5:30 PM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote: > On Tue, Jun 2, 2009 at 4:59 PM, Axel Polleres <axel.polleres@deri.org> wrote: >>> Incidentally, the fact that you can filter using the DATATYPE function >>> in sparql is another hint that something is amiss. By my earlier >>> analysis, the DATATYPE function should never return rdf:PlainLiteral, >>> according to our spec. >> >> Indeed, *according to our spec*. This is why I prefer Option 2 which makes >> this point clear. > > I would modify it to not try to make it invalid, but instead to make > it clear we say nothing about the lexical to value mapping of such > literals within RDF and SPARQL. In RDF, before you attempt a D-interpretation or to prove a D-entailment, you have to decide what D you want to use. You are forced to make a choice. So saying nothing isn't an option if rdf:PlainLiteral is in the domain of D. To implement what you suggest (saying nothing), the datatype map would have to be prohibited from having an assignment for the URI rdf:PlainLiteral, as an individual datatype also does not have the ability to "say nothing". If I understand RDF semantics correctly you would then get no entailments involving such typed literal nodes (loosely speaking), making them as ill-behaved as a literal node with a randomly selected URI after ^^ (and I'm not sure exactly how ill-behaved that is). You could separately constrain interpretations by saying that the URI rdf:PlainLiteral must be interpreted to be the datatype described in section 3 of our spec; this would allow use of the URI in other contexts. It just wouldn't be in the datatype map. This seems really weird to me, and I haven't chased through the consequences to SPARQL, OWL, RIF, or anything else, so I can't recommend this approach. Jonathan
Received on Wednesday, 3 June 2009 14:33:54 UTC