Below, I'm going to discuss how I think information can be retrieved and edited using a Semantic Web/Microcontent Client.
One of the things about RDF is that things (resources) are identified by a URI. While it is sometimes the case that that you can enter the URI into a browser and get some RDF-XML out, this isn't always true. There are many resources identified by an HTTP URI which aren't actually accessible at that location. Some XML namespaces are like this as well. I find this disturbing as using http:// at the beginning implies that the URI has something to do with HTTP. In fact, the XHTML namespace might as well be mailto:email@example.com. Actually, it should probably be something starting with urn:
Anyway, because resource URIs in RDF don't indicate where information can be found, I need some consistent way to find RDF data based only on the resource. It's possible that such a thing has been suggested by someone already. I'd imagine something like the following.
In this case, the resource 'urn:ndeakin:jun10-1' would be retrieved from the URL 'http://www.xulplanet.com/ndeakin/weblog', which would be some script which looks to see if knows about the resource and returns information about it, or returns nothing if not found.
The user's client (say a Semantic Web Client or Microcontent Client), would recognize the URL form, and could decide what to do based on user settings. For instance, if the resource was already known by the client, it would get the new data and add it to the existing data. Or, the client could modify the URL, based on some user setting, to retrieve from:
This gets the same resource from a different source, which might return additional info about trackbacks and so forth. The example that actually got me started into the Semantic Web is like this:
The client could handle this directly, or it could transform into the following four separate requests (the sites don't actually exist, I've made them up):
This would gather general movie info, local showtimes, the localized rating and the trailer all combined together. Of course, I wouldn't expect Disney to actually allow this kind of thing, but it's just an idea. The client would combine the data from all four sources and present them into a single UI to the user. Here comes something even more interesting. What if I changed my Weblog request above to:
The only change is that the HTTP request type is now PUT instead of GET. This request would allow me to post information about the resource to my weblog. Hmmm, but what about if I wanted to post about a movie? I'd probably do this:
Notice the similarity to those examples above. The resource is the same, but I'm doing a PUT instead of a GET and the URL is different. Let's say now that Jack, who works for Showtimes for Vancouver, wants to upload the showtimes for the movie Finding Nemo for the week. First, he'd enter the resource ID for the movie into his client, the same kind of client everyone else uses (actually, he'd use a search facility that converts movie titles into IDs). The client might translate the ID into a request:
This returns various info about the movie, presented to Jack in a dynamic UI. Jack has customized the UI for the work he does at Showtimes for Vancouver. Although other users would just see general movie info, Jack sees a Showtimes Entry Area. Of course, this might be pre-filled from the data coming from the theatres that supply the showtime information. (which is just a request to their site with the same resource ID.) Jack enters data and hits the Upload button, which makes the following request:
Then, when a user makes the four request list from earlier, he would see the updated showtimes. Remember, no URLs were entered -- the client figured them out based on user settings and previous requests. Jack entered only a movie title, uploaded showtimes, and then users may view the info using the movie title. Also note, in this example, Showtimes for Vancouver doesn't have a Web site, just Jack entering movie showtimes.
Of course, all this requires that companies start using RDF for everything, and this system makes it harder for them to slap enormous logos and long license agreements on everything, so it probably won't ever happen. But then again, I'd rather build things for the user, which is why I'm interested.