W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > December 2005

QName production in SPARQL grammar

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Tue, 13 Dec 2005 12:12:41 +0000
Message-ID: <439EBAB9.1000904@hpl.hp.com>
To: public-rdf-dawg-comments@w3.org

This is a *personal* comment concerning


Sorry this comment is very late, if it's too late to be considered, I 
would understand.

Despite the lateness, I think the suggested changes are all quite small, 
and I hope that they could be made fairly easily.

The third comment would have substantive consequences, the other three 
comments are editorial.


I had four comments to make mainly about the QNAME production and 
related productions in the SPARQL grammar.




The overall thrust of the comments is to support the use of
eg:name as an abbreviation mechanism, and to clarify its relationship 
with the qname production from XML Namespaces.

COMMENT 1: [NAMESPACE] reference

I note that the [NAMEPSACE] reference is informative not normative.
However, the sentence in which it is used:
"The PREFIX keyword binds a prefix to a namespace IRI [NAMESPACE]. "
has a most natural reading in which a PREFIX cannot be used to bind a 
prefix to an IRI that does not identify a namespace (this reading would 
require a normative reference).
Given that the reference is informative I take that reading to not be 
the intended reading.
This sentence could hence be clarified by the editorial change of:
"The PREFIX keyword binds a prefix to an IRI. "
and deleting the [NAMESPACE] reference

I also note that the example use of PREFIX:

PREFIX  data:  <http://example.org/foaf/>

does not bind a prefix to a namespace IRI, but does bind a prefix to an IRI.

COMMENT 2: redundancy in grammar

I think the following editorial change leaves the language wholly 
unchanged, but slightly simplifies the grammar.


[64]    	QName  	  ::=    	QNAME | QNAME_NS
[68]    	QNAME  	  ::=    	NCNAME_PREFIX? ':' NCNAME?


[64]    	QName  	  ::=    	NCNAME_PREFIX? ':' NCNAME?

and delete production 68.

COMMENT 3: Minor change to NCNAME production

My understanding is that these productions are taken from XML 1.1, and 
modified to:

a) prohibit _ as a namespace prefix, because of confusion with blank nodes
b) prohibit a trailing '.' because of syntactic confusion with '.' as a 
SPARQL puncutation character.
c) permit ':' and 'prefix:' and ':name' as QNAMEs
(I am not quite sure why, maybe compatibility with N3?)

I am unclear as to why these changes were made while maintaining 
restrictions from XML 1.1 that are not applicable in the SPARQL context. 
The most striking is the prohibition on digits immediately after the :.
This prevents an IRI such as:


being abbreviated by the QNAME production.

I suggest a fix of replacing production 90

[90]    	NCNAME  	  ::=    	NCCHAR1 ((NCCHAR|'.')* NCCHAR)?

[90]    	NCNAME  	  ::=      ((NCCHAR|'.')* NCCHAR

This maintains the restriction that the NCNAME production does not end 
in a '.', and is non-emtpy, but removes the restrictions on the first 
character, and would allow abbreviations of IRIs that end in a non 
NCCHAR followed by a sequence of digits.

COMMENT 4: Editorial change to rename productions

The use of the term QNAME for this production is confusing.
A QNAME is defined in XML Namespaces as appropriate for XML elements and 
attributes, for referring to a name from a namespace.

The use in SPARQL is an abbreviation mechanism, and not a mechanism for 
selecting a name from a namespace, indeed as we have seen under comment 
1, the abbreviation need not identify a namespace. For example, the 
following renamings would make that clearer, and would make it clearer 
that the syntactic restrictions on this mechanism in SPARQL, while 
similar to those for qnames in XML, are different.

QName            => Abbr_IRI
QNAME            => ABBR_IRI
NCCHAR1p         => ABBR_CHAR1p
NCCHAR1          => ABBR_CHAR1
NCCHAR           => ABBR_CHAR

This would reduce the common confusion between the abbreviation 
mechanism which is widely used in the semantic web community, and the 
QName mechansim used in XML Namespaces.


Once again apologies for the lateness, these issues have struck me more 
forcefully recently as a result of discussions concerning XHTML2, where 
similarly there is a need for an IRI abbreviation mechanism, which 
should be familiar, yet disjoint from bnode identifiers ...

Received on Tuesday, 13 December 2005 12:14:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:07 UTC