- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 12 Sep 2005 12:15:49 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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