Warning:
This wiki has been archived and is now read-only.
SPARQL11 and RDF11
Contents
1 Using SPARQL1.1 with RDF1.1
- Abstract
-
The SPARQL comprises a set of specifications for querying, manipulating and updating RDF data, namely:
- SPARQL 1.1 Query Language
- SPARQL 1.1 Update
- SPARQL 1.1 Protocol for RDF
- SPARQL 1.1 Graph Store HTTP Protocol
- SPARQL 1.1 Entailment Regimes
- SPARQL 1.1 Service Description
- SPARQL 1.1 Federation Extensions
- SPARQL 1.1 Conformance Tests
- SPARQL 1.1 Query Results CSV and TSV Formats
- SPARQL 1.1 Query Results JSON Format
- SPARQL Query Results XML Format
All these specifications are based on the Resource Description Framework (RDF) specifications in their 2004 version [@@@ Ref RDF concepts, @@@ Ref RDF MT]. The W3C RDF working group is currently revising these specifications towards RDF1.1. The present document describes how SPARQL1.1 is to be used with RDF1.1.
- Status of this Document
- @@update This is an automatically generated Mediawiki page, made from some sort of W3C-style spec.
Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
1.1 Introduction
RDF1.1 introduces several changes compared to RDF (2004) which make the handling of legacy RDF data different from handling graphs that have been published as RDF1.1. Particularly, there will be no more distinction between plain literals @@@add link/ref @@@ and literals typed as xs:string.
This affects SPARQL 1.1 in several ways. In the following sections, we list affected documents of the SPARQL1.1 specification which would be affected by different treatment of literals in RDF and RDF 1.1.
1.2 SPARQL 1.1 Query Language
Here is a run through of effects on the spec: I may well have missed something.
It is leaving the possibility open for systems that need cope with the ways things are to day. Simply changing SPARQL to uniformly work on xsd:strings is, IMHO, unworkable. Application writers don't write their own SPARQL engines - deployed applications have to be checked and potential updated. Maybe a few chnages - but significant costs to requalify apps.
1.2.1 Functions
The functions are the most affected - operator dispatch table needs revising but that seems to have a natural update.
Quite a few functions take arguments that are simple literals or xsd:strings - these just work. Things that return simple literals need more thought.
Ones to pay attention to:
B2.1/ Use of simple literals for the lexical form:
STR, STRDT, STRLANG
STRLANG is particular tricky here
PlainLiteralWithLang STRLANG(lexicalForm, langTag)
Its workable to make the args xsd:strings - it's explaining why STRLANG(literalWithDatatype, X) removes the datatype that seems messy.
B2.2/ DATATYPE
DATATYPE("foo"@en) = ?????
B2.3/ LANG
What kind of thing is the lang tag itself? Currently, a simple literal.
1.2.2 BGP Matching
This is mainly a matter of compatibility.
The RDF abstract syntax will only have xsd:strings. All simple literals will have been "upgraded" to xsd:strings.
Assuming { ?x :p "x"^^xsd:string } is legal (but the not-preferred form) then there needs to be words about matching data :x :p "x" where it used not to, and the other way round.
1.3 SPARQL1.1 Update
@@@ Just parsing "x" to "x"^^xsd:String is going to break when updating existing data with SPARQL 1.1 + xsd:String. At least some words about what this change means will be needed.
DELETE DATA { ?x :p "x" }
1.4 SPARQL1.1 Service Description
@@@ Should we propose some feature to describe that RDF 1.1 is supported?
1.5 SPARQL1.1 Entailment
@@@ I suppose the non-distinction between string-typed literals and plain literals affects all entailment regimes "below" D-Entailment.