- 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