Re: deciding on rdf:PlainLiteral this week

Pat asks:
> ?? I thought I had this understood, but now I am genuinely confused. Why
> would the datatype of a plain literal NOT be rdf:PlainLiteral? Surely,
> calling this a datatype, and saying that it applies to plain literal syntax,
> means exactly that. If it does not mean that, what on earth does it mean?
> (***)
>
> Maybe the idea is, plain literals in undecorated, undatatyped, vanilla RDF
> have no datatype, but they do when this new datatype is 'recognized' (or
> chose your favorite term here; when the appropriate form of D-entailment is
> in use, for whatever reason). But if something like this is true, how can
> SPARQL tell the difference between RDF which is plain RDF (where "abc" has
> no datatype) and RDF which recognizes the new datatype (in which "abc" has
> the new datatype)?

My understanding is that the *SPARQL* DATATYPE function is a function
on syntax (or abstract syntax (= graph, for RDF)). Here's what it's
signature is documented to be:

IRI   DATATYPE (typed literal typedLit)
IRI   DATATYPE (simple literal simpleLit)

Since the syntax of RDF does not contain typed rdf:PlainLiteral
literals the DATATYPE function, under standard SPARQL semantics would
never return rdf:PlainLiteral.

Moreover, the extension of SPARQL to entailment regimes says that it
"is defined for a subset of RDF graphs called well-formed for the
regime". By RDF graphs, I understand it is meant the abstract *syntax*
of RDF. Since the RDF abstract syntax (graph) has no typed
rdf:PlainLiteral literals, my understanding is that the SPARQL
DATATYPE function could therefore also not return rdf:PlainLiteral.

As a check I looked to see whether there is any specified interaction
between the DATATYPE function and extensions of SPARQL to entailment
regimes and I see none. Of course entailments might introduce new RDF
literal terms, but as we've seen, typed rdf:PlainLiteral literals
can't be among those. I'd also point out that all BGP extension
language refers to RDF graphs, so I don't see any chance that typed
rdf:PlainLiteral literals will ever be introduced via that route.

What about bindings/answer sets? SPARQL says: "Graph pattern matching
produces a solution sequence, where each solution has a set of
bindings of variables to RDF terms". Since RDF terms are things in RDF
graphs, and we can't have typed rdf:PlainLiteral literals in RDF
graphs, there can't be typed rdf:PlainLiteral literals in answers. The
extension language does not modify this condition.

Therefore, to Andy's points, I conclude that the spec already prevents
what he is worried about, however it couldn't hurt to include
informative text that makes this clear.

There is only one case that I can see that might be surprising:

If you do the query corresponding to an earlier question Pat had about
entailment

{ :s :p "foo"^^xs:string.
  :s :p _:b.
  _:b :p ?type }

One might get, in one entailment regime, only a binding for ?type that
is xs:string, and in another only a binding for ?type that is
rdf:PlainLiteral. Of course neither of these bindings will obtain in
standard SPARQL with simple entailment.

-Alan

Received on Monday, 1 June 2009 20:40:53 UTC