W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: [Fwd: Comments on SPARQL from the XML Query and the XSL WGs]

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 14 Nov 2005 08:34:20 -0500
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20051114133420.GH17622@w3.org>
On Tue, Nov 08, 2005 at 06:24:41PM +0000, Seaborne, Andy wrote:
> 
> Proposed reply:
> 
> Outstanding: Things in [[ ]] below:
> 
> + Do we want to link to
>   http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/
> 
> + Eric/Dan: please suggest text for 5

done

> + EricP - coudl you confirm the namespace comment (near end) is fixed and
>   that I fixed the query in 11.2.3.7 correctly.  Thanks.

done

> I added an example to rq23 for reification.
> 
> 	Andy
> 
> -------- Original Message --------
> > From: Ashok Malhotra <>
> > Date: 13 September 2005 16:28
> >
> > Notes on SPARQL Query Language for RDF
> > Last Call Draft July 21, 2005
> >
> > The XML Query and the XSL WGs have reviewed the SPARQL last call draft.
> > Our comments are below.  We apologize for the late delivery of these
> > comments.  By way of explanation we mention that the WGs were on summer
> > vacation during the month of August.
> >
> > 1. If RDF triples are stored in a relational database (in-memory
> > databases are available now) then SQL can be used to query them.  SQL
> > has much more power and is a well-known language, but there are a
> > couple of features peculiar to RDF that are unique in SPARQL such as
> > the OPTIONAL clause.  An analysis of how much overlap there is between
> > SQL and SPARQL would be useful.
> 
> There are already implementations that based on SQL so useful experience 
> reports are beginning to appear and will continue to appear throughout this 
> phase and the CR process.
> 
> > 2. SPARQL cannot return a function of a stored value.  For example, if
> > a website stores the profit of a corporation, SPARQL cannot be used to
> > return the profit multiplied by a currency conversion factor, if a
> > currency is specified.  This seems like a serious limitation.
> 
> In the requirements gathering process [1], the working group did not 
> identify this as a critical feature so it didn't make the design in this 
> working group. There are applications already written using prototype 
>  SPARQL systems so we hope that what is in the current draft is sufficient 
> for a large enough class of applications.
> 
> [1] http://www.w3.org/TR/rdf-dawg-uc/
> 
> > 3. The document uses a describe-by-examples style.  This is easy to
> > understand but can give the impression that the language is more
> > restrictive than it is.  For example, if you read section 2 you get the
> > impression that only exact matches are supported.  Only much later do
> > you find out that, in fact, functions and operators are also supported.
> 
> This is hard - having a document that meets the different sections of the 
> SPARQL audience.  We choose the describe-by-examples style but we do 
> recognize that this isn't to everyone's taste.  We do provide a 
> consolidated set of definitions [2] which is mechanically extracted from 
> the document.
> 
> [2] http://www.w3.org/2001/sw/DataAccess/rq23/defns.html
> and live:
> 
> http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F
> 2001%2Fsw%2FDataAccess%2Frq23%2Fdefns.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F
> 2001%2Fsw%2FDataAccess%2Frq23%2F&transform=Submit
> 
> (apologies for the split link)
> 
> > 3. How is reification supported?  That is, how does SPARQL handle
> > values that are themselves triples?  I assume nested queries are
> > required but there is no discussion of support for this important
> > aspect of RDF.  Dan Connolly replied to this comment on the previous
> > draft and explained how it could be done but an example in text would
> > be illuminating.
> 
> An example using reification has been added (section 2.9) showing that 
> reification is a vocabulary that can occur in the data.
> 
> http://www.w3.org/2001/sw/DataAccess/rq23/#queryReification
> 
> 
> > 4. Presumably, RDF encodes metadata about data that is represented as
> > XML.  If this is the case, why are all the XML Schema datatypes not
> > supported?  See section 11.2.  An accompanying document
> > [http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/] that discusses
> > the use of XML Schema datatypes in RDF/OWL discusses the problems with
> > the duration datatype and recommends the use of the two subtypes of
> > duration xdt:yearMonthDuration and xdt:dayTimeDuration.  These
> > datatypes are not discussed in this document.
> 
> The SPARQL draft defines the datatypes that can be expected in any SPARQL 
> service.  This does not stop an implementation offering more than this 
> minimum.
> 
> [[Note to DAWG : we may wish to reference that SWBPD note if and when it 
> becomes stable]]
> 
> >
> > 5. Instead of the XML Schema datatype anyURI, RDF and SPARQL uses a
> > datatype that they refine called IRI.  The earlier version of the
> > document said that the RDF datatype IRI is a restriction of the XML
> > Schema datatype anyURI in that only absolute URIs are supported.  We
> > commented that it might have been simpler just to support the XML
> > Schema datatype and call out this restriction.  The definition of this
> > datatype has been removed from this document and is said to be
> > contained in the RDF Data Model.  We were unable to locate this
> > document.

The RDF abstract syntax distinguishes between URIrefs
 http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabulary
and typed literals
 http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Literals
(which use XML Schema datatypes
 http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Datatypes-intro
). These can be constrasted with the following RDF/XML fragments
  <rdf:Description>
    <foaf:homepage rdf:resource=
       "http://www.w3.org/People/Eric/"/>
    <foo:homepageStr rdf:datatype=
       "http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI"
       >http://www.w3.org/People/Eric/</foo:homepageStr>
    <foo:shoeSize rdf:datatype=
       "http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#integer"
       >9</foo:shoeSize>
    <foo:writesMailAbout rdf:resource=
       "http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI">
  <rdf:Description>

The RDF model distinguishes the types of the homepage and the
homepageStr. In this example, the homepage and writesMailAbout objects
are URIrefs (called IRIs in SPARQL). The homepageStr and shoeSize
objects are types literals (anyURI and integer, respectively).

URIrefs identify web resources. The literals with the type anyURI
are URIs. Thus, the strlen of the URIref
http://www.w3.org/People/Eric/ is 10710 while the strlen of
"http://www.w3.org/People/Eric/" is 30.

SPARQL preserves this model distinction.

> > 6. String comparison is defined only using the code point collation.
> > Other collations are not supported.  This may be a significant
> > limitation.
> 
> Code point collation is always required.  Access to other collections can 
> be done through a custom function.
> 
> >
> > 7. Section 3.  Decimal values cannot be written as literals.  This
> > seems like a needless limitation.  Suggest SPARQL use the literal
> > definitions in XPath 2.0.
> 
> [[In progress]]
> 
> >
> > 8. Section 3.1 has a very brief section entitled "Matching Arbitrary
> > Datatypes".   There is no motivation for this and little explanation
> > for how this works.  Motivation and detailed semantics should be provided.
> 
> > 9. Section 11.2.1.3 introduces the function isURI.  Is this necessary?
> > There is another function that returns the datatype of a variable.
> 
> 
> > 10 sop:str returns the string representation of an r:IRI.  It's not
> > clear what this does.  In the example, it strips the scheme from the
> > IRI.  Does it perform any escaping or unescaping?
> 
> 
> > Some typos:
> > -	Section 2: The simplest graph pattern is the triple patterns,
> 
> Fixed.
> 
> > -	Section 11, subsection Namespaces:
> > XML Schema datatypes with the prefix op: xs:
> 
> [[EricP?  This is fixed isn't it?]]

yes. I just wiped out the last of those pesky bastards* (including
a couple spurious namespace decls in the sample results format at
http://www.w3.org/2001/sw/DataAccess/rq23/#select

* I'm not sure that this will keep them out in the future. That
depends on whether their rabbit-like proliferation was do to
reproduction or spontaneous generation.

> > -  Section 11.1 last para says XMLSchema[]
> > -	There are a number of references to an XML Schema datatype called
> > xs:int.  In fact, the XML datatype is called xs:integer.
> 
> Fixed
> 
> [[11.2.3.7 seemed into be wrong and I fixed it.]]

I think this was
http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#func-datatype

which had
  _:b  eg:shoeSize     "42"^^xsd:integer .
  ...
  FILTER ( datatype(?size) = xsd:int )
which is now
  _:b  eg:shoeSize     "42"^^xsd:integer .
  ...
  FILTER ( datatype(?size) = xsd:integer )
which seems fixed to me.

http://www.w3.org/2001/sw/DataAccess/rq23/#func-datatype

Since that appears to be your doing, thanks Andy!

> > In conclusion, the XML Query and XSL working groups believe that the
> > SPARQL specification will need considerable rework and another last
> > call WD before it is ready to advance. In particular, we believe that
> > the spec needs to be made more rigorous and formal, we believe that it
> > needs to be more clearly differentiated from SQL, and it needs to be
> > more clearly and carefully aligned with other W3C Recommendations
> > including XML Schema and XPath 2.0.
> >
> > All the best, Ashok
> 
> 	Thank you very much for the comments
> 	Andy
> 
> 

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Monday, 14 November 2005 13:34:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT