A key concept to understand in this discussion is the notion of an information resource...but first let's get to grips with resources.
A resource is pretty much anything that we want to talk about; you, me, XTech 2006, John Lennon, the 322 bus route, the city of Paris, meeting room 2 (and its projector), a Zanussi washing-machine, and so on. These things are anything that we may usefully make statements about, and in turn share those statements with each other.
An information resource is a very specific subset of this enormous list of things, and it is those things that you interact with on the web. Why do we need to pull these resources out and make them special, as opposed to, say, car resources or planet resources? The answer actually goes to the heart of the discussion we have just had in the earlier sections.
Let's assume that we all want to share data about the XTech 2006 conference; we might want to say "get this flight to XTech 2006", or "tickets for XTech 2006 cost this much", or "Steven Pemberton is giving a tutorial on XForms and XHTML 2 at XTech 2006". RDF and the idea of URIs gives us a mechanism for identifying the resource 'XTech 2006' (go on, get with the programme...call it a resource...you won't regret it!) in such a way that we can all know that we're talking about the same thing; that mechanism is for us all to agree on a URI that represents this conference and nothing else.
Once we have agreed on this URI, then the information you have carefully put together about hotels that are close to the conference venue, could be mixed with my data about flights from London, and someone else's data about the topics that will be discussed, to build a package of useful data.
So how do we choose this all-important URI? It's probably best to let the conference organisers decide and then leverage the DNS architecture--they could choose a URI in a domain that they own and control. If they do this, then they would most likely decide to use the conference home page:
<http://xtech06.usefulinc.com/>
That's all well and good, but let's work through what happens when the conference organisers add metadata to this web-page.
Let's say they add something simple like a modification date; the problem now is that we're right back squarely into our 'implied knowledge' problem from the first section, since we now need to know whether the modification date applies to the conference agenda or just to the document page that has been modified.
A similar problem arises if we want to have a unique URI to identify the conference sessions so that we can make statements about them--perhaps we want to suggest sessions to avoid, or we want to give them stars afterwards to indicate how good they were. My session on RDFa is identified by this URI:
<http://xtech06.usefulinc.com/schedule/detail/58>
but if you opened the document from that URL and found that there was a dc:creator tag, what exactly would it indicate? Would it tell you the name of the page author, or me, the session author? Tricky...
TAG
The W3C's tag group got round this problem by saying that the URI that identifies my session in RDF-space must not be the URI I just quoted, since that is a web-page. Trying to use it to represent both resources (the session and the web-page) causes lots of problems because you only have one URI, and with one URI you can only unambiguously talk about one thing. To put it another way, the session and the web page describing the session, are distinct--there are two resources, not one.
It's important to be clear on the implications of this. No-one is saying that the URI for the session can't be within the address-space of the web-site, so it's fine for my session to be identified as something like this:
<http://xtech06.usefulinc.com/data/session/58>
The crucial thing about making this separation is that if we now talk about this resource (by using this URI) and make statements like who created it, where it is located, when it was last modifed, how long it is, what its subject matter is, and so on, we know without any doubt that we are talking about the session, and not the page about the session (that is still located at http://xtech06.usefulinc.com/schedule/detail/58.)
We're inching towards a solution, but now we have two further problems; how do we get distinct URIs for our two resources, and how do we put metadata in our document so that it's clear when we're talking about the session and when we're talking about the web-page.