Re: Subclass of Thing/Resource

On Fri, 3 Mar 2000, Guha wrote:
> Ok, in theory we can assign everything a unique identifier. The
> reason URL's are used so much more than URNs is that the
> URL contains enough information for an application to be able
> to do something with it.

Yeah, the way I think about it, is that with URIs which happen to be
URLs, applications easily know how to 'ask the Web' about that
resource. I expect/hope to be able to 'ask the Web' about various less
location-oriented URIs (eg. Handles, DOIs) once we've got some
conventions in place for accessing and querying networked RDF services.

> What should we be able to do with the RDF identifier for a thing
> (in the context of the SW). Determine what kind of thing it is
> (by just looking inside the identifier)? Determine where to get
> more information about it (by just looking inside the identifier)?
> Pass the identifier along to some other machine and ask it
> where we can find more information about the object denoted
> by the identifier?

The problem being that right now, there's no easy way to identify a
metadata service that can provide information about non-URL URIs.

I'm basically assuming without argument (perhaps someone will
disagree...) that URI resolution information is (perhaps rather
boringly) simply more (meta)data about an abstractly nameable resource.
Furthermore, that this allows for some technology sharing, in that
resolution services become simply a specialised species of RDF service
that can describe some given URI (eg. as sketched in

We've some cheesy prototypes elaborating on this point to back up this
position. The example I've been playing with is taking the Handle
( system of identifiers, projecting into non-URL
URI space (eg. hdl:/10.1000/79, a DOI identifier), then sketching what
an RDF-based resolution service might look like.

If anyone's interested, feedback welcomed on
(these sketch an RDF vocabulary for describing how an abstract URI such
as hdl:/10.1000/79 relates to the concrete locations of the documents it
identifier).  Example below [1]. This is a live demo that wraps the
Handle URI resolution system in an RDF layer, turning Handle resolution
messages into RDF descriptions.

If I'm right, the issue boils down to the broader question of how we can
characterise metadata services to make it easy, scaleable etc to
identify the service that knows about some URI. That knowledge might be
related to URI resolution, Web annotations, PICS-esque ratings etc.



<web:RDF xmlns:web=""
<web:Description about="hdl:/10.1045/january99-bearman">
  <demo:webLoc web:resource=""/>
  <demo:webLoc web:resource=""/>
  <demo:webLoc web:resource=""/>
  <demo:webLoc web:resource=""/>

Received on Friday, 3 March 2000 20:20:23 UTC