Resource-Type Revisited (httpRange-14)

The Resource-Type header has been proposed before, but today I
realised why it and its brethren are really useful. Let me walk you
through a scenario.

So here's the URI of TimBL's FOAF file:

When I put that in my Semantic Web Browser (I'm using Arcs, but
Tabulator and others do similar things), it lets me view a bunch of
information about TimBL. It finds by smushing that the following URIs
all identify TimBL:


Now, when I'm looking at facts about TimBL, it's not unreasonable that
I should want to find out more information. Where should I look? Well,
the first and most obvious place to look is at the URIs above. We
already know that the first URI, without its fragment, is the URI of
the FOAF file that I just loaded. What about the other two? What are
they? What sort of information will they give me?

As it happens, the second is Bookmashup data about TimBL (a human can
tell from the URI but my browser can't), but I dunno what the third
one is. After loading it I find that it gives me journal data.

Wouldn't it be nifty if TimBL could, in his FOAF file, say things
about those data sources? How would you imagine he'd do that? If you
thought of the following, then you'd be *wrong*:

   dc:title "Bookmashup Data about TimBL" .

   dc:title "Journals TimBL has Contributed To" .

The problem, of course, is that these URIs identify TimBL the person,
not documentation about TimBL. So when my SW browser smushes them, I

   foaf:name "Tim Berners-Lee";
   dc:title "Bookmashup Data about TimBL";
   dc:title "Journals TimBL has Contributed To" .

   foaf:name "Tim Berners-Lee";
   dc:title "Bookmashup Data about TimBL";
   dc:title "Journals TimBL has Contributed To" .

   foaf:name "Tim Berners-Lee";
   dc:title "Bookmashup Data about TimBL";
   dc:title "Journals TimBL has Contributed To" .

Otherwise known as a bloomin' mess.

The only way that we're able to have HTTP URIs denoting people at the
moment is to have them 303, which is what the URIs above in fact do.
For example:

HTTP/1.1 303 See Other

So we *could* do this to give the information we want to give:

   dc:title "Journals TimBL has Contributed To" .

This is the URI that the URI denoting TimBL 303-see-others to.

But it's impractical to do it this way for two reasons, one
inconvenient for the producer and one inconvenient for the consumer:

1) If you want to make statements about the information resource that
you eventually get, such as TimBL might want to do to give it a title
in his FOAF file, then you have to do a HEAD on it to look it up.
2) Worst of all, this means that Semantic Web browsers have to do HEAD
requests on things before they can tell what the titles are.

That point 2) is especially, from my point of view, a disaster. It
simply doesn't scale if you have hundreds of sources of data for
something and you want the user to be able to browse through them by
keyword, search their titles, and so on. You'd have to HEAD every
single source! It ain't no good.

So I figured that this would be okay:

[ :from "";
  dc:title "Journals TimBL has Contributed To" ] .

And indeed it is, as long as you make sure to use a *literal* for the
URI. If you used an RDF URI Reference like this:

[ :from <>;
  dc:title "Journals TimBL has Contributed To" ] .

It could be smushed to, for example:

[ :form <>;
   foaf:name "Tim Berners-Lee";
   dc:title "Bookmashup Data about TimBL";
   dc:title "Journals TimBL has Contributed To" ] .

Which is our bloomin' mess all over again. So it has to be a literal.

This got me thinking about TimBL's Description-Id proposal:
Alternative to 303 response: Description-ID: header
Date: Tue, 4 Dec 2007 19:53:55 -0500

I said I'd come back to it when I understood the implications more
fully, and so I'm coming back to it now. It's actually fine as a
proposal because it's not much different from our current 303
technique. But that's also the downside: it's not much different from
our current 303 technique! In other words, you still have to maintain
two URIs: in the TimBL/Journal-info case that's one for the person,
and one for the journal information about the person.

But thanks to the :from property, we no longer really need a URI for
the information resource. So we can revive Sandro Hawke's old
suggestion from 2003...

So one might call the HTTP header "Resource-Type", in nice
parallel to "Content-Type".
]]] -

Which Jonathan Borden explained rather clearly here:

I generally agree. "Site" is one type of resource, perhaps its special
enough to get its own HTTP header (?) but why not just (example HTTP
response headers):


would solve this problem, as well as [httpRange-14] in a general fashion.
]]] -

In fact, as you can hopefully see, Resource-Description is the same as
TimBL's Description-Id suggestion. All of this is quite obvious stuff.

So with all these bits and pieces—the :from property, Resource-Type,
and Resource-Description/Description-Id—that'd give us some fairly
nice tools for making the Web a bit more Semantic Web friendly.

TimBL asked me a question about Resource-Type:

<timbl> sbp, though, if you are sending the description in the body,
why do you need the type in the header?

Of course we *could* do something like this:

InformationResource: no

That'd be the simplest thing to do. But I think that it's nice to have
a minimal amount of documentation, and if we're saying that this
strange thing in HTTP space isn't an information resource, we might as
well at the very least tell people what it is. Yeah it's a bit
redundant, but I think it's really handy as a header: HEAD is the way
to do queries to find the *essential* properties of something, and
type seems to be a rather essential property.

I'd be happy with "InformationResource: no", too, having said that.
Anything that lets me use a *single* 200 to give information about
people and the moon and whatever is fine by me. As long as we have the
:from property too, that's all we need to say stuff about the
information resource.

Sean B. Palmer,

Received on Friday, 4 January 2008 15:30:30 UTC