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

Re: #rdfms-difference-between-ID-and-about (every document is in the Web)

From: Dan Connolly <connolly@w3.org>
Date: Fri, 15 Jun 2001 09:20:55 -0500
Message-ID: <3B2A19C7.5B43A7DF@w3.org>
To: Graham Klyne <Graham.Klyne@Baltimore.com>
CC: rdf core <w3c-rdfcore-wg@w3.org>
Graham Klyne wrote:
> At 08:18 AM 6/15/01 -0500, Dan Connolly wrote:
> >Graham Klyne wrote:
> > >
> > > At 02:29 AM 6/15/01 -0500, Dan Connolly wrote:
> > > > > RDF absolutely has to make sense even outside the context of
> > > > > an enclosing document which can be given a uri. so ...
> > > >
> > > >So... what? That doesn't make any sense to me.
> > > >
> > > >An RDF document is an XML document. Each XML document
> > > >has a base URI (cf the infoset spec).
> > >
> > > If this is  true, then it is not possible to transfer RDF data in transient
> > > protocol elements.
> >
> >Why not? Transient things are resources too; you may or
> >may not specify what their URI is (in the case
> >of a mail messge, it would be mid:....); that doesn't mean
> >they don't have one.
> Well, by definition (as I understand these things) it's only a resource if
> it has a URI.

I think you've slightly overstated the case there,
but the argument holds even the way you've phrased it, so...

> The fact that something can have a URI (and anything can, right?) doesn't
> mean that it's got one.

Suppose I say that it does. There's no argument to
refute me, is there? i.e. there's no reason not
to adopt this as an axiom.

> (Not every mail message has a Message-ID header,
> from which the mid: is derived.)

Those messages can be named just like all the things
that aren't mail messages at all can be named.

>  From a practical viewpoint, having a URI but not knowing what it is
> doesn't seem to be significantly different from not having a URI.

But this isn't an issue of practical viewpoints; it's
an argument of architectural constraints -- or rather,
lack of them. So the difference is significant.

You trust that I have a birthday even though you don't
know it, right? By the same token, it seems easy
enough to accept that resources have URIs even though
those URIs aren't always specified.

> > > Which means that (say) the CC/PP spec, formulated *by design* as a *format*
> > > only for client capability data, cannot be regarded as a valid RDF
> > application.
> >
> >I don't see how that follows.
> Because (by my lights) a CC/PP profile may be some data that doesn't have a
> URI.

We disagree on that.

>  Which (by your lights) means that it cannot be valid XML hence not
> valid RDF.
> > > But what is the status of information that is not "on the Web"?
> >
> >Just think of everything as "on the Web".
> I don't.  That sounds to me more like a religion, or act of faith, than a
> state of affairs.

Well, that's how architecture and mathematics work, no?

i.e. by the same token, nothing compells you to agree that
2+2=4, nor that the DNS has a unique root.
But it follows from generally accepted axioms,
so you do agree, right?

> >  It's a matter
> >of perspective. There aren't any constraints in the
> >design of the Web that allow you to deduce a contradiction
> >from saying "every document is on the Web".
> More important, I think, than the lack of a contradiction is a sense of
> common understanding (which, also, is an act of faith...).

Alas, it's true that a lot of folks think of the Web
as HTTP+HTML. They speak of "the Web or email or ftp"
when they should say "HTTP or email or ftp, all of which
are part of the Web." The telephone system is also
part of The Web, as is IRC etc.
cf rough notes
and running code

I agree that this common understanding is somewhat lacking
and important to achieve; I plan to spend considerable
effort developing it over the next few years.
But meanwhile, the 10 year history of the Web
is evidence that this axiom is useful; can we agree that
for the purposes of the RDF spec, every document is in the Web?

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Friday, 15 June 2001 10:21:02 UTC

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