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

Response for:
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0002

This now only depends on #rdfSemantics  (and #owlDisjunction (minorly))

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


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

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

The document now says:
"There is a set of query variables V, where V is 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 and sorted out already:
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".
   >>   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)
   >>

@@ awaiting #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 multiple matching under
entailment.)

@@ check when #owlDisjunction resolved.

   >>
   >> ...
   >>
   >> 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 Thursday, 10 November 2005 17:06:43 UTC