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

Re: Resolution for rdfms-fragments

From: Dan Connolly <connolly@w3.org>
Date: Thu, 06 Dec 2001 17:44:12 -0600
Message-ID: <3C1002CC.B3578FD@w3.org>
To: Aaron Swartz <me@aaronsw.com>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Aaron Swartz wrote:
> 
> Here is a simple resolution to the rdfms-fragments issue. Define that as
> URI-refs are turned back into full URIs (thru the base URI), if a '#' exists
> it is encoded as %23.

and if %23 already occurs in the URI reference, then what?

Why in the world would you want to do anything like that, anyway?
I don't understand what you're trying to achieve.

I re-read the entry in the issues list
  http://www.w3.org/2000/03/rdf-tracking/#rdfms-fragments
It seems to say that folks are confused; that doesn't
necessarily mean the spec is broken. ;-)

The model theory (http://www.w3.org/TR/rdf-mt/)
gives a perfectly good semantics
for all relative URI references. It treats them all the same,
whether they have #'s in them or not.
It depends in no way on the MIME spec, the HTTP spec, etc.

RDF doesn't give a flip what these identifiers denote;
it just tells you that whatever they denote, you
can always deduce A from (and A B) and you
can deduce (exists (?x) (P ?x)) from (P a).
[RDFS gives you a few more such rules].

Can you point out which part of whatever spec bugs you?
Or give a use case that you think is insufficiently
specified? (i.e. not a foo/bar/baz example)
Or some piece of code that's acting funny,
or difficult to write or interoperate with?

> So:
> 
> [...]
> <rdf:Description rdf:about="http://rdf.example.org/foo#bar">
> <rdf:value>baz</rdf:value>
> </rdf:Description>
> [...]
> 
> Would represent this N-Triple:
> 
> <http://rdf.example.org/foo%23bar>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns%23value> "baz" .
> 
> Cheers,
> 
> --
> [ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 6 December 2001 18:44:17 EST

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