W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2001

RE: What are allowable property URIs?

From: Jonathan Borden <jborden@mediaone.net>
Date: Thu, 15 Feb 2001 06:13:45 -0500
To: "Gabe Beged-Dov" <begeddov@jfinity.com>, "Aaron Swartz" <aswartz@swartzfam.com>
Cc: "Dan Brickley" <danbri@w3.org>, <www-rdf-interest@w3.org>
Message-ID: <003201c09740$5cdb7040$0201a8c0@ne.mediaone.net>
Gabe Beged-Dov wrote:
> >
> > > As far as I can tell, there isn't an operational need for a qname to
> > > have a non-empty local-part.
> >
> > Unfortunately, this is in violation of the XML names spec:
> >
> >     QName     ::=     (Prefix ':')? LocalPart
> >     NCName    ::=     (Letter | '_') (NCNameChar)*
>
> Yeah, it would be too easy if we could actually do any kind of
> round-tripping without changes to the syntax or model or both :-(.
>
> Some more half-baked ideas to go with the original degenerate qname
> idea...
>
> I can't see any way to do the mapping from an arbitrary URI to a qname
> without introducing a stand-in URI (at least without alot of extra
> machinery). Either way, it would require a change to RDF/XML
> processors to recognize whatever signalling mechanisms were used. This
> presumes that you want to allow arbitrary URI for properties and
> typednodes. If you are willing to constrain the allowable URI to be
> URIref that only use NCname for the fragmentID then you don't need any
> extra machinery.

Without getting too too complicated, also remember that a URI reference is
defined as:

URI-reference := [absoluteURI | relativeURI] ["#" fragment-id]

The idea of explicitly using a "#" to delimit the local name from the
namespace URI in a typedNode qname is not half baked (IHMO) but grounded in
RFC 2396 itself.

There's no need to constrain allowable URIs at all, instead redefine the
qname -> URI construction mechanism as I've suggested in
http://www.openhealth.org/RDF/QNameToURI.htm i.e. NSURI "#" localname

-Jonathan
>
Received on Thursday, 15 February 2001 06:11:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:48 GMT