Errata

The book suggests installing ARQ in order to try out the SPARQL examples from a command line. Unfortunately it seems that ARQ is no longer enough to provide this functionality at it is now necessary to install the full version of Jena which includes ARQ. This is described in more detail on the Jena users forum here http://mail-archives.apache.org/mod_mbox/incubator-jena-users/201204.mbox/%3C001201cd16b7$31bae2d0$9530a870$@on.net%3E

Note from the Author or Editor:
In ARQ's transition to an Apache project, its packaging changed, and I am revising the instructions to take this into account for the expanded edition of the book.

"ab:i8301" should be "d:i8301"

Note from the Author or Editor:
I will make the change; I have the most recent version from svn.
fixed 2013-04-07

In the listing ex025.rq you use the predicate `d:musicalArtist` which returns no results as it appears that dbpedia now uses `d:artist`. This form wouldn't let me link an example or use un-prefixed terms, sorry.

Note from the Author or Editor:
Thanks! And I see that it does work with d:artist now, so I will update that.

The 2nd line should read:

d:item342 dm:invoiced false .

if ex033.ttl, ex034.ttl amnd ox035.rdf all store the same triples (as is claimed in the last sentence of this section about 'Data Typing', before the next section on 'Making RDF More Readable with Language Tags and Labels')

The other two examples ex033.ttl and ex035.rdf both show the object to be false (not true) for the predicate dm:invoiced

Note from the Author or Editor:
I will change ex034.ttl example to have the second line say false instead of true.

fixed 2013-04-07

NOT EXISTS is used directly in the query when the SPARQL 1.1 specification states that NOT EXISTS can only be used as a FILTER

i.e. should be FILTER(NOT EXISTS { ?s ab:workTel ?workNum }) instead

Note from the Author or Editor:
Revise example to use NOT EXISTS within a FILTER; review description around it; check any other usage of NOT EXISTS for the same issue.
fixed 2013-04-07

The query reads

PREFIX ab: <http://learningsparql.com/ns/addressbook#>
SELECT ?first ?last
WHERE
{
?s ab:firstName ?first .
?s ab:lastName ?last .
NOT EXISTS { ?s ab:workTel ?workNum }
}

but (unlike MINUS) NOT EXISTS should only be in a FILTER expression. I.e., the correct query is

PREFIX ab: <http://learningsparql.com/ns/addressbook#>
SELECT ?first ?last
WHERE
{
?s ab:firstName ?first .
?s ab:lastName ?last .
FILTER NOT EXISTS { ?s ab:workTel ?workNum }
}

(FWIW, the first version does not pass the SPARQL validator at http://www.sparql.org/query-validator.html).

thanks,
HTH

Note from the Author or Editor:
I see that 17.4.1.4 refers to EXISTS as a FILTER operator, so I will change the example to use the FILTER keyword.
fixed 2013-04-07

In ex167.rq and subsequent examples that use SERVICE the author writes a full SELECT query inside each SERVICE clause which is unecessary.

Anything inside a SERVICE clause is packaged up as a SELECT * WHERE { } query so the effect of writing this may be to send a sub-query to the remote service (depending on whether the SPARQL processor does any special optimisation/handling for this case) which will not be supported when talking to SPARQL 1.0 only endpoints.

It would be simpler to write like so:

SERVICE
{
<http://dbpedia.org/resource/Joseph_Hocking> ?p ?o .
}

Note from the Author or Editor:
Remove inner SELECT * WHERE {} from ex167.rq and subsequent examples that do this; review descriptions of them.
fixed 2013-04-07

The book says that single quotes can be used for Turtle strings (and the example turtle file uses them). According to the spec at http://www.w3.org/TeamSubmission/turtle/, however, only double quotes are allowed.

I wish they were allowed. It would make sense and fit in better with SPARQL. I know that rapper is okay with single-quotes but not all parsers accept them.

HTH

Note from the Author or Editor:
OK, between sections 2.1 and 10 of the Turtle spec I see that single quotes are allowed in SPARQL but not Turtle, at least not in the spec's current form. I will fix the book to reflect this.

fixed 2013-04-07
update 4/8: that was an older draft of the Turtle spec. Latest one does allow single quotes to delimit strings: http://www.w3.org/2010/01/Turtle/#prod-turtle2-STRING_LITERAL1

There are some conversion errors in the answers given:

* boolean true converts to 1
* float converts to int and decimal (unless it's too big or Inf, -Inf or NaN).

I believe the correct table would be:

----------------------------------------------------------------------------------------
| o | integerTest | decimalTest | floatTest | doubleTest |
========================================================================================
| 3 | 3 | "3"^^xsd:decimal | "3"^^xsd:float | "3"^^xsd:double |
| _:b0 | | | | |
| "5 bucks" | | | | |
| 4 | 4 | "4"^^xsd:decimal | "4"^^xsd:float | "4"^^xsd:double |
| dbr:Montr?al | | | | |
| true | 1 | 1.0 | 1.0E0 | 1.0E0 |
| 1.0e5 | 100000 | 100000.0 | "1.0e5"^^xsd:float | 1.0e5 |
----------------------------------------------------------------------------------------

Note from the Author or Editor:
I have learned that this is a bug in ARQ that has been fixed for the next release, 2.9, so I will redo the example with that release when it is available.
fixed 2013-04-07

Any non-zero and non-NaN number should convert to "true"^^xsd:boolean (cf. http://www.w3.org/TR/xpath-functions/#casting-boolean). So the output of the table should be


-----------------------------------------------------------------------------------------
| o | stringTest | booleanTest |
=========================================================================================
| 3 | "3"^^xsd:string | true |
| "true" | "true"^^xsd:string | true |
| "2011-11-14T14:30:00"^^xsd:dateTime | "2011-11-14T14:30:00"^^xsd:string | |
| _:b0 | | |
| "5 bucks" | "5 bucks"^^xsd:string | |
| "2011-11-12" | "2011-11-12"^^xsd:string | |
| 4 | "4"^^xsd:string | true |
| "True" | "True"^^xsd:string | |
| true | "true"^^xsd:string | true |
| "2011-11-13T14:30:00" | "2011-11-13T14:30:00"^^xsd:string | |
| 1.0e5 | "1.0e5"^^xsd:string | true |
-----------------------------------------------------------------------------------------

Note from the Author or Editor:
I have learned that this is a bug in ARQ that has been fixed for the next release, 2.9, so I will redo the example with that release when it is available.
fixed 2013-04-07

The encode_for_uri function should actually leave the full-stops (the periods) alone so that the answer should be


----------------------------------------------------------------------
| encodeTest |
======================================================================
| "http%3A%2F%2Fwww.learnsparql.com%2Fcgi%2Ffunc1%26color%3Dred" |
| "My%20String" |
----------------------------------------------------------------------

Note from the Author or Editor:
What the book shows is the ARQ output, and it looks like ARQ has been changed since then to leave the full stops alone. I will replace the sample output with a new version.

fixed 2013-04-07

In the Bear Trap point on this page it states "When you use the USING keyword don't use the WITH keyword"

The subsequent pages then go on to show examples doing exactly that and discuss the effect of it in a somewhat disjointed and inconsistent way.

For example page 201 goes on to say "the USING keyword in a DELETE update request overrides whatever a WITH clause says about a graph to delete from" which is in fact incorrect.

The SPARQL 1.1 Update specification goes into detail on this but my general understanding is as follows:
- WITH sets the graph to be used in any place in the update request where a graph is not explicitly specified by a GRAPH clause
- USING and USING NAMED sets the graph(s) to be used for the WHERE clause only, again the WHERE clause may use explicit GRAPH clauses which will override these

Note from the Author or Editor:
Revise examples to not use USING with WITH, revise descriptions around them, have Rob review. (The bear trap paragraph was in response to a reviewer comment about my first use of these together, and I didn't notice that the examples following that made the same mistake.)
fixed 2013-04-07