W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2001

RE: Resolution for rdfms-fragments

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 7 Dec 2001 09:44:45 -0000
To: "Aaron Swartz" <me@aaronsw.com>, "Dan Connolly" <connolly@w3.org>
Cc: "RDF Core" <w3c-rdfcore-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDAEKCCCAA.jjc@hplb.hpl.hp.com>

The problem with this argument^H^H^H^H^H^H^H^H^Hdiscussion is that you're
both right, which is why it is making fairly painful progress.

Aaron is clearly correct when he says that RDF specs and usage do not
conform (even a little bit) with RFC 2396 section 4.1.

Dan is also right to defend the current specs and usage as not actually
causing real problems in practice.

As far as I am concerned RDF really could be the Random Description
Framework (cf:
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Dec/0028.html ). For
RDF, in my view, the important part about URI-refs is the U bit not anything
else. It is just a convenient framework for identifiers. In the case when
the URIref is a property or class name in RDF then sometimes you are really
intended to retrieve the base URI and treating it as an RDF document find
the description of that URIref in order to understand what it means; but
that is only rarely and, that is as close to RFC 2396 section 4.1. as it
gets.

If you want to know what these identifiers mean then ask the RDF Model
Theory, not the RFC.

Hence in my view :) the RDF specs could (but shouldn't) start with the
following disclaimer:
[[[
  In these specifications a URI means a lexical form that conforms with the
production URI-reference in RFC 2396; however any other resemblence with RFC
2396 is co-incidental except in the one case when the URI reference is:
+ a URL reference
+ the URL refers to an RDF document (in any serialization)
In which case, it is conventional that the RDF document provides a schema in
RDFS or some other schema language which may give a decription of the URI
reference.
]]]

In practice, RDF usage picks and chooses and modifies RFC 2396, we could
make this explicit, or we could let it continue unclarified. I don't think
we can undo it.

I am convinced that Aaron's proposed resolution is way too radical - but he
has all the good arguments (except pragmaticism).



Jeremy
Received on Friday, 7 December 2001 04:47:30 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:43:01 EDT