aboutEachPrefix? was Re: Namespaces wihtout "#" Was: Few CWM Bugs

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