- From: Reto Bachmann-Gmuer <reto@gmuer.ch>
- Date: Tue, 07 Jun 2005 09:33:22 +0200
- To: James Cerra <jfcst24_public@yahoo.com>
- Cc: semantic-web@w3.org
Jimmy,
> > > Note that <http://gmuer.ch/aü> is not a valid URI can can never be
> > > a resource name. The string <http://gmuer.ch/a%C3%BC> is a valid URI
> > > and so can be a resource name.
> >
> > Why is the first an invalid Resource name? I agree that it is not a
> > valid URI, but as I understand rdf-concepts resources are identified by
> > URIRefs and http://gmuer.ch/aü is a valid URIRef. Both URIRefs resolve
> > to the same URI but they identify two distinct resources.
>
> URI strings MUST consist of only the characters allowed per RFC 3986:
>
> A-Z a-z 0-9 "-" "." "_" "~"
> ":" "/" "?" "#" "[" "]" "@"
> "!" "$" "&" "'" "(" ")" "*" "+" ";" "="
> "%"
>
> The string "http://gmuer.ch/aü" contains letters outside those constraints, so
> it is not a well-formed URI. Your browser may automatically percent escape
> characters outside that set in your character encoding of choice (probably
> UTF-8) for your convenience.
As I said, I agree that it is not a valid URI. But it is a valid URIRef
according to section 6.4 of rdf-concepts
(http://www.w3.org/TR/rdf-concepts/#dfn-URI-reference):
A URI reference within an RDF graph (an RDF URI reference) is a
Unicode string [UNICODE] that:
* does not contain any control characters ( #x00 - #x1F,
#x7F-#x9F)
* and would produce a valid URI character sequence (per
RFC2396 [URI], sections 2.1) representing an absolute
URI with optional fragment identifier when subjected to
the encoding described below.
The only reason I see for rdf-concepts to define the identity criterias
for URIRef is that the resource is identified by their URIRef, not by
their URIs.
Section 3.2 (http://www.w3.org/TR/rdf-concepts/#section-URI-Vocabulary)
puzzles me saying
A node may be a URI with optional fragment identifier (URI
reference, or URIref), a literal, or blank [...]
since much less Strings are "URI with optional fragment identifier" than
valid URIRefs according to section 6.4.
reto
Received on Tuesday, 7 June 2005 07:33:26 UTC