- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 21 Nov 2005 19:39:53 -0600
- To: Graham Klyne <GK@ninebynine.org>
- Cc: public-rdf-dawg-comments@w3.org
We still don't have a response to all your comments, as they touch on a rather involved issue http://www.w3.org/2001/sw/DataAccess/issues#rdfSemantics But by way of status report, here's a report from the editors.. http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0208.html and a copy for convenience... 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 -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Tuesday, 22 November 2005 01:40:10 UTC