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
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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:07 UTC