Fwd: Comments on last-call SPARQL draft 20050721, section 2

Editorial changes made in response to
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0002

Not all the comments are editorial.

Someone might care to comment on the OWL and literals-as-subjects comment.

	Andy


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.)

There is an example in section 3 where literal syntax is discussed.  I'd 
rather not have example of one part of literal syntax and the rest elsewhere here.

I have added "or qname" to "or an optional datatype IRI or qname".


> 
> ...
> 
> 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?

Not editorial.  Will ask #g what its about.


> 
> ...
> 
> 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 - my reading of that is that as a processor that 
is not responsible for cvreating teh 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.

The set of all variables is some set disjoint from RDF-T.

Other comments suggest that some definition is needed.

Maybe

"There is a set of query variables V, where V is disjoint from RDF-T"

[The reason this worms round bNodes in queries is that RDF-T includes RDF-B 
the set of all bnodes *in RDF graphs*.]

Chnage no made - awaiting suggestions.

> 
> ...
> 
> 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.

Not editorial.
Comments?

> 
> ...
> 
> Section 2.4, "Definition: Query Solution"
> 
> What does it mean for a "pattern solution" to be "matching dataset DS". 
>   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. 
> 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)
> 

Seems to be subsumed by the issue #rdfSemantics

> ...
> 
> 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.)

(Note: Single triple matching does not extend to multipl matching under 
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.

Done.

"""
A blank node can appear in a query pattern. A blank node in a query pattern 
may match any RDF term.
"""

> 
> ...
> 
> 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
> 

	Andy

Received on Monday, 12 September 2005 11:16:16 UTC