Re: The RDF 1.1 Literal Quiz

On 18/05/11 19:22, Richard Cyganiak wrote:
> The RDF 1.1 Literal Quiz
> ------------------------
>
> Let's pretend we live in the future and RDF 1.1 has just been
published, including this working group's attempt to clean up string
literals.
>
> Now here's a quiz with some RDF trivia questions.
>
> What are the answers that you'd like to see? Please keep them short

What's the prize?

> --
along the lines of “Yes”, “No”, “Don't care”, “Don't prefer but ok”, “Oh
yes please please please”, “WTF!?!?”, “Formal objection!”
>
> (I tried to phrase the questions in terms of user-visible behaviour
and not spec-internal mechanisms. I hope we can get some
non-controversial test cases out of this, and pinpoint where we disagree
on desired behaviour. If you provide responses, then feel free to add
additional questions.)
>
>
>
> Q1. Does this RDF graph (written in Turtle) have one triple?
>
>   <a>  <b>  1 .
>   <a>  <b>  "1"^^xsd:integer .

Yes

> Q2. Does this RDF graph (written in Turtle) have one triple?
>
>   <a>  <c>  "foo" .
>   <a>  <c>  "foo"^^xsd:string .

Usually.  In 2013, many systems still treat these as different.

Such systems are considered "mostly harmless" [+]

> Q3. Is this be a valid Turtle file?
>
>   <a>  <b>  "foo"^^rdf:PlainLiteral .

No.  It violates the PlainLiteral spec.

> Q4. Is a parser allowed to unify "foo" and "foo"^^xsd:string into a single form while parsing?

s/unify/convert/ then yes.

SHOULD convert.

>
> Q5. Is this a valid N-Triples file?
>
>   <a>  <b>  "foo" .

Yes

((Well, no (for completely unrelated reasons).
N-Triples RDF 1.1 does/may not allow relative IRIs.))

> Q6. Is this a valid N-Triples file?
>
>   <a>  <b>  "foo"^^rdf:PlainLiteral .

No.  It violates the PlainLiteral spec.

> Q7. Is this a valid N-Triples file?
>
>   <a>  <b>  "foo"@en .

Yes

> Q8. Is this a valid N-Triples file?
>
>   <a>  <b>  "foo"^^xsd:string .

Yes

> Q9. Is this true in SPARQL?
>
>   datatype("foo") == xsd:string

Yes.

> Q10. Is this true in SPARQL?
>
>   datatype("foo") == error

No.

> Q11. Is this true in SPARQL?
>
>   datatype("foo") == rdf:PlainLiteral

No.

> Q12. Is this true in SPARQL?
>
>   datatype("foo"@en) == xsd:string

No

> Q13. Is this true in SPARQL?
>
>   datatype("foo"@en) == error

Yes

> Q14. Is this true in SPARQL?
>
>   datatype("foo"@en) == rdf:PlainLiteral

No [*]

>
> Q15. Is this true in SPARQL?
>
>   datatype("foo"@en) == rdflang:en

No

> Q16. Does the literal in this RDF/XML fragment have a language tag?
>
>   <rdf:Description rdf:about="a" xml:lang="en">
>     <rdf:b>foo</rdf:b>
>   </rdf:Description>

Yes.

> Q17. Does the literal in this RDF/XML fragment have a language tag?
>
>   <rdf:Description rdf:about="a" xml:lang="en">
>     <rdf:b rdf:datatype="&xsd;string">foo</rdf:b>
>   </rdf:Description>

No.

> For each of the following pairs of statements, if the statement on the left is true, then is the statement on the right true as well in a system that supports datatype inference (specifically, {xsd:string}-Entailment)?
>
> Q18. {<a>  <b>  "foo" . } =>  {<a>  <b>  "foo"^^xsd:string . }

Yes

> Q19. {<a>  <b>  "foo"^^xsd:string . } =>  {<a>  <b>  "foo" . }

Yes

> Q20. {<a>  <b>  "foo" . } =>  {<a>  <b>  "foo"@en . }

No.

> Q21. {<a>  <b>  "foo"@en . } =>  {<a>  <b>  "foo" . }

No.

> Q22. {<a>  <b>  "foo"@en . } =>  {<a>  <b>  "foo"@en-GB . }

No.

> Q23. {<a>  <b>  "foo"@en-GB . } =>  {<a>  <b>  "foo"@en . }

No
(but "yes" under "language entailment" defined in RDF 1.1.1.1.1.1.)

langMatches("en-GB", "en") is true
langMatches("en", "en-GB") is false

>
> Q24. {<a>  <b>  "foo"@fr . } =>  {<a>  <b>  "foo"@en . }

No.

	Andy

[+] With or without a towel.

[*] Errors in SPARQL seem to be causing some confusion.

One cause of errors is no defined function matching the call.

So datatype("foo"@en) is an error in SPARQL 1.0 because there isn't a 
function for datatype(plain literal), only datatype(typed literal) or
datatype(simple literal).

An error is not a value - it causes the entire expression to be an error 
unless it is handled by a special form (e.g. COALESCE, IF, BOUND). 
SPARQL valuation is a 3-valued logic; FILTER itself turns "error" into 
false.

If something is an error, then an extension to SPARQL is to define what 
happens in that situation.

So
	FILTER ( 4 = "IIII"^^my:roman )
is an error in unextended SPARQL but can be added by a processor.

	Andy

Received on Thursday, 19 May 2011 10:40:56 UTC