We still don't have a response to all your comments, as they
touch on a rather involved issue
But by way of status report, here's a report from the editors..
and a copy for convenience...
This now only depends on #rdfSemantics (and #owlDisjunction (minorly))
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".
>> 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:
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
RFC 3987 (IRI) says: 22.214.171.124:
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
>> 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:
>> 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 .
>> _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.
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
@@ 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
>> Better, I think, to delete the clause "It behaves as a variable; " --
>> the remaining text seems sufficient to the purpose here.
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).
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
|Free forum by Nabble||Edit this page|