Re: #rdfms-difference-between-ID-and-about

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.

The fact that something can have a URI (and anything can, right?) doesn't 
mean that it's got one. (Not every mail message has a Message-ID header, 
from which the mid: is derived.)

 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.

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

>  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...).

#g

Received on Friday, 15 June 2001 09:48:15 UTC