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

RE: Formation of RDF terms

From: Jonathan Borden <jborden@mediaone.net>
Date: Sun, 28 Jan 2001 19:38:38 -0500
To: "Dave Beckett" <dave.beckett@bristol.ac.uk>
Cc: "RDF Interest" <www-rdf-interest@w3.org>
Message-ID: <004401c0898b$d2521cb0$0201a8c0@ne.mediaone.net>
Dave Beckett wrote:

> >>>Jonathan Borden said:
> > Dave Beckett wrote:
> > >
> > > ... and this is exactly what we have been discussing.  This property
> > > allows the relationship to be made without doing any delving into
> > > parsing URIs - which isn't possible for general URIs.  I think RDF
> > > shouldn't get into this game.
> >
> > Unfortunately RDF is already in this game in RDF M&S 1.0. Every
> typedNode
> > qname is converted into a URI which is the subject of the rdf:type.
> > ...
> No.

As I said. A typedNode qname is not always correctly converted into a URI
according to RDF M&S 1.0. Is there a problem with my example? Even if
roundtripping XML -> RDF -> XML is a non-goal (which *is* suprising for
something which is supposed to serialize RDF models), the current RDF rule
for qname -> URI doesn't work.

> The XML syntax in the RDF M&S document constructs URIs from XML
> namespace prefix URIs and XML element names (qnames).  It never takes
> URIs and de-constructs them - which is what I was saying.  You cannot
> take an arbitrary URI and deconstruct it to a namespace and a qname
> (in RDF).

	According to RFC 2396 a URI reference is defined as (EBNF):

	[absoluteURI | relativeURI] ['#' fragmentId]

	According to the definition of a URI reference, you *can* deconstruct a URI
into a namespace and localName (where the localName is the fragmentId )

> In the RDF formal model (section 5) this is even more important since
> there are no XML syntax concepts at all.  URIs are 'black boxes' that
> are never broken open.

	Not according to RFC 2396, which contains a whole bunch of normative EBNF
productions that allow parsing an URI. A URI is simply not a random string,
or unique identifier, at least according to its normative definition.

> >
> > <xsd:unsignedInt rdf:about="http://www.foo.org/someNumber/123">
> > 	...
> > </xsd:unsignedInt>
> >
> > Ought RDF applications use XML Schema datatypes?
> The RDF M&S Recommendation date was February 1999.  The XML schema
> series are still candidate recommendations dated late 2000 and are
> thus several years later.  Thus the RDF M&S document couldn't really
> depend on XML schema!   [ However in a revised document ... ]
> Maybe there should be a note on pros/cons of namespaces that intend
> to be used with RDF to avoid some of the things you mention
> (e.g. dealing with if the namespaces should end in # or /)

There are applications which cannot always choose the namespace encountered.
Such applications, if they are to use RDF, need to be able to deal with
arbitrary namespaces.

For example RDDL which uses XLink syntax. It could have used RDF syntax
except for this single killer issue. Certainly if even the W3C XML Schema WG
does not care to use RDF friendly namespaces why ought other applications?
Doesn't this say something? Purity is fine except when it goes against

> > What triples ought be generated? Certainly not:
> > http://www.w3.org/2000/10/XMLSchemaunsignedInt
> >
> > N3 already appends a '#' to such namespaces in a bind.
> Lets leave N3 out of this and deal with the XML syntax in the
> standard rather than experiments for more friendly syntax.
If the RDF syntax were adequate, there would be no need for so many
'experiments' at producing something better. Again my problem is not with
RDF Model which I think is terrific, rather Syntax. Do you really think that
the current RDF syntax is adequate? --  or might not be revisited circa 2001
now that we have XPointer, XML Base, XML Schema etc. I don't even think that
the syntax needs to be totally trashed, rather tweaked here and there. It's
good to tweak things every couple of years.

Received on Sunday, 28 January 2001 19:35:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:27 UTC