- From: Jonathan Borden <jborden@mediaone.net>
- Date: Wed, 26 Dec 2001 01:41:01 -0500
- To: "Tim Berners-Lee" <timbl@w3.org>, "Dan Brickley" <danbri@w3.org>
- Cc: "Sean B. Palmer" <sean@mysterylights.com>, "Dan Connolly" <connolly@w3.org>, <www-rdf-interest@w3.org>
It seems to me that in order to say something like this in RDF we really do need the "aboutEachPrefix" construct, in which case one can: <rdf:Description rdf:aboutEachPrefx="http:"> <rdf:type rdf:resource="...#Document"> </rdf:Description> unfortunately it has been removed from the current RDF syntax. Can one state this using the current RDF? What I am looking for is an unambiguous, machine processable, mechanism for knowing types and other properties of URI subspaces (now that URIs are not opaque -- which is fine) Jonathan > True. A resource for a non-HTTP space can be whatever that URI space says > it > is. It is just HTTP which really creates a world of documents. > > mailto: for example, defines a space of mailboxes which are not documents. > I should have limited what I said to the http: space. > > Tim > > ----- Original Message ----- > From: "Jonathan Borden" <jborden@mediaone.net> > To: "Tim Berners-Lee" <timbl@w3.org>; "Dan Brickley" <danbri@w3.org> > Cc: "Sean B. Palmer" <sean@mysterylights.com>; "Dan Connolly" > <connolly@w3.org>; <www-rdf-interest@w3.org> > Sent: Saturday, December 22, 2001 10:39 AM > Subject: Re: Namespaces wihtout "#" Was: Few CWM Bugs > > > > Tim Berners-Lee wrote: > > > > > > > > > The second issue is more significant. In my worldview, > > > > > (which I claim to be (a) consistent and (b) useful) > > > > > http://example.org/x is a document. You can't reuse > > > > > its URI for an abstract thing without a change to HTTP. > > > > > > > > In-principle plausible, although _please_ define "document". > > > > > > I uyse the term "document" because unfortunately "resource" has been > > > used differently in URI and RDF specs. I mean by "document" > > > "resource" as in URI. DAML uses the term "Thing" to mean what RDF > > > terms a resource. > > > > This is really helpful, yet when I read the RFC 2396 definition of a > > resource I don't see how a resource can be _limited_ to only things which > > are documents: > > > > "A resource can be anything that has identity. Familiar examples include > an > > electronic document, an image, a service (e.g., "today's weather report > for > > Los Angeles"), and a collection of other resources. Not all resources are > > network "retrievable"; e.g., human beings, corporations, and bound books > in > > a library can also be considered resources. " > > > > This language clearly states, to my very best reading, that a _document_ > is > > a subClass of a _resource_ and a _human being_ is another subClass of > > _resource_. This is why I cannot understand why a plain old URI (i.e. > > without fragment identifer) cannot identify a person. Perhaps you are > > saying that the _type_ of resource is indicated by the URI scheme? i.e. > that > > people would be indicated e.g. > > > > person://smith/joe > > > > > > > > When the content-type is RDF or N3, then a document can be used > > > to describe people and planes and ideas. These can be identified > > > (in N3) by using the localname of concept within the document > > > as a fragment identifier. (I think the same should be true of RDF/XML). > > > > Ok, I buy this. Here you say that people, places and things can be > > identified by URI References. This still does not solve the problem that > RFC > > 2396 says what URIs themselves may identify... > > > > > > >.The distinction > > > > is only useful if it can be defined clearly enough to implement to. > > > > > > Well, you certianly can't return a person across the net, so the > > > distinction is > > > not that fine ;-) > > > > Again, RFC 2396 explicitly does not limit resources to things that are > > network retrievable, so I need more guidance here. > > > > Perhaps the problem is that many people treat RFCs as axioms and in trying > > to understand how 'logic on the Web' will work in practice, > inconsistencies > > are problematic. > > > > Jonathan > > > >
Received on Wednesday, 26 December 2001 01:15:39 UTC