Re: Comments on last-call SPARQL draft 20050721, section 2 [OK?]

Graham Klyne wrote:
> [Unfortunately, the last-call period for this coincided with a period of 
> extended unavailability for me, so I'm rather late getting my comments 
> together.  So far, I've got comments on section 2;  I'll send in more 
> later if I can get them in on time.]
> 
> ...
> 
> Section 2.1, "Query term syntax", para 2
> 
> It's not immediately clear that the qname form can be used for a 
> datatype IRI;  maybe slip in an example here to show this is an allowed 
> form?  (e.g. that 42, "42"^^xsd:integer and "42"^^<http://...#integer> 
> are forms of the same literal.)

I have added "or prefixed name" to "or an optional datatype IRI or prefixed
name".  In addition, the docuemnt talks about "prefixed names" rather than QNames.

http://www.w3.org/2001/sw/DataAccess/rq23/#QTSynLiterals

> 
> ...
> 
> Section 2.1, "Query term syntax", para 4
> 
> I feel that allowing a prefix to be redefined as described could create 
> some small unnecessary complication for implementations that don't 
> process the query sequentially, and creates scope for implementation 
> errors.  I would suggest not allowing prefixes to be redefined.  Is 
> there a compelling case for allowing such redefinition?
> 
> ...

Discussed on list:
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0050

The working group considered whether redefinition should be an error or
allowed.  The consenus is reflected in the document.

> 
> Section 2.1, "Query term syntax", para 5
> 
> I'm a bit hazy on the details, but the discussion of combining 
> characters goes against my recollection that RDF specifies that 
> URI-references muct be in normal form C, which I think was intended to 
> avoid some of these issues.  I think that SPARQL should follow RDF in 
> the forms of URI/IRI that it allows.

SPARQL follows the IRI spec - as a processor that
is not responsible for creating the IRIs, it should not
apply normalization because it needs to allow access to
unnormalized data.

RFC 3987 (IRI) says: 5.3.2.2:

"""
Equivalence of IRIs MUST rely on the assumption that IRIs are
appropriately pre-character-normalized rather than apply character
normalization when comparing two IRIs.   The exceptions are conversion
from a non-digital form, and conversion from a non-UCS-based
character encoding to a UCS-based character encoding. In these cases,
NFC or a normalizing transcoder using NFC MUST be used for
interoperability.
"""



> 
> ...
> 
> Section 2.2, "Definition: Query Variable"
> 
> I'm really having a hard time figuring what this definition is trying to 
> say.  It refers to *the* set V, which has not been defined, and which 
> seems to be almost completely spurious to the definition of "query 
> variable".  I think this is saying simply that a query vbariable is any 
> value that is not in RDF-T.
> 

This definition introduces the term variable - the important point is that 
variables are disjoint from RDF-T

> ...
> 
> Section 2.3
> 
> Concerning the reference to literals-as-subjects.  Is this still an 
> option for the Semantic Web family?  I understand that OWL (or OWL-DL) 
> requires that subjects be URIs.  Maybe not a problem, but I thought I'd 
> mention it.

Discussed:
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0051
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0055

> 
> ...
> 
> Section 2.4, "Definition: Query Solution"
> 
> What does it mean for a "pattern solution" to be "matching dataset DS". 

This has been expanded upon.  There is a "target graph" from the dataset which
is what the pattern matches against unless it is an RDF Dataset Graph pattern
(GRAPH).

>   I can't see any definition of what it means to be "matching".  I think 
> this idea could be defined more precisely by reference to the concept of 
> graph instances as defined in the RDF formal semantics specification. 

The WG has modified the definition of basic pattern matching: SPARQL is built
around the concept of matching a basic pattern (a set of triple patterns) so
that different forms of entailment can be plugged in.

> As it stands, I think there could be awkward questions raised;  e.g. does
>    ?v a b .
> match
>    _v a b .
> ?  (that is, after substitutions have been applied, which allow some 
> query variables to remain unreplaced)
> 
> ...
> 
> Section 2.5
> 
> The paragraph beginning "For a basic graph pattern to match..." is 
> rather awkward to read.  There are two mentions of "solution" which 
> grammatically can be distinct, but logically are the same.
> 
> Suggest (something like):  For a basic graph pattern to match some 
> target dataset, there must be a pattern solution using which each of the 
> triple patterns matches the target dataset.


Reworded as:

"""
For a basic graph pattern to match some dataset, there must be a solution
where each of the triple patterns matches the dataset with that solution.
"""

> 
> (Refering back to my previous comment about the definition of matching, 
> this seems to allow a definition that builds upon a definition of 
> matching a single triple pattern against a target dataset, which could 
> be done quite precisely by enumeration of options.)


Under some entailment systems, matching single triple patterns does not extend
so easily to basic patterns.  SPARQL is defined in terms of simple entailment.

> 
> ...
> 
> Section 2.7
> 
> I think it's confusing to say that a blank node behaves as a variable, 
> as a blank node in a query pattern doesn't return a binding.  Also, a 
> query variable can be bound to a blank node, but not to another query 
> variable.
> 
> Better, I think, to delete the clause "It behaves as a variable; " -- 
> the remaining text seems sufficient to the purpose here.
> 

Under the revised definition of matching, blank nodes in queries are matched 
via simple entailment.  Theer is now no need for explicit text about their 
behaviour.

> ...
> 
> That's all for now.  I'll try and do some more later (but I'll be 
> travelling and may be unable to do so by the last-call deadline).
> 
> #g
> 

I hope this addresses the comments you raised.  Please let us know if it does.

(If you could send an email reply with [CLOSED] in the subject, the manegment
scripts will pick it up.)

	Andy

Received on Thursday, 22 December 2005 11:41:52 UTC