Tom Scott, of the BBC, comments on Jamie’s comments about Jamie's work on the design of BBC’s /programmes service in his post Web design 2.0 - it’s all about the resource and its URL. It touches on something I constantly hammer on: Everything important should have a URL Put another way: Can I link to it? That's the way I phrase it in meetings when people say something like "I am-developing/have-developed web blah-blah-blah so-on-and-so-forth." The next thing out of my mouth is " can I link to it?" And I don't mean link to a page that shows it. I mean directly link to the "web thing" (i.e. "resource"; i.e. "data") that was created. Sure, it's a blanket statement that ignores nuances and such (I don't even want to get into ETags with the people). I just find that it is a useful question for an "inside the Enterprise" environment in trying to improve IT architecture — it's catchy; it's to the point; and it can be (in general) easily comprehendible by people. (By the way, the web design at derivadow.com (which, according to the site's colophon is based on the " ChaosTheory" Wordpress theme) looks a lot like Khio Vinh's subtraction.com.)

I have been thinking a lot lately about using wikis as a storage backend for data-- not text for an article, but for metadata. This idea started a few weeks back when Jeremy Smith and I were discussing my proposed maps.case.edu site as part of the upcoming location-based services offerings. I proposed a RESTful interface to XML data so any user or service on campus could obtain details about, say a specific building. You could query maps.case.edu/xml/buildings/WICK and be sent an XML document with details about the building, eg

<building abbr="WICK" name="Wickenden Building">
  <departments>
    <department code="EBME" name="Biomedical Engineering" />
  </departments>
  <eateries>
    <food name="Bag-It" />
  </eateries>
  <geo>
    <lat>41.5031</lat>
    <lon>-81.6084</lat>
  </geo>
</building>

Jeremy and I both thought this would be a cool idea, as we love providing easy-to-access and use services to the campus. Before we committed to the project, Jeremy pondered who would maintain the site. Who would create entries for new buildings as they were built? Destroyed? Who would update the data when things changed? We both thought for a second and said, "Isn't this what a wiki is for?" Since then, I have been thinking of ways to do just this. I have this idea in my head for a MediaWiki extension which allows users to embed XML documents in a page. These XML documents can be extracted at page save time and stored in a separate database table to provide easy access to any external services that might want to access the data. As an added bonus, I could probably work out some XSLT tranforms (perhaps in the form of MediaWiki templates) to convert the XML documents into displayable text in the wiki. From the high-level perspective, this data repository model makes almost perfect sense. Why limit shared data to be controlled by a select number of people? Find a mistake, just log in and fix it yourself! Your change will instantly propogate to any service that accesses the data. Speaking of services, access to data would never be easier. After creating an XML document in a page, you could go to say http://wiki.case.edu/misc/xml/buildings to retrieve an XML document of all the XML documents stored in the wiki. You could then use this data to power location-based services. Want a list of all departments at Case, just access http://wiki.case.edu/misc/xml/departments. Any XML document stored in the wiki could be accessed by simply supplying its root element name. There are problems with my model, however. I believe the main hurdle to be the standardization of the XML documents. Some people won't know what XML is and will be confused when they see it when editing a page. Others won't follow the defined structure. The second problem is data poisoning. Nobody likes getting their web service poisoned. But since we are using a wiki for the data storage, identifying the culprits is all too easy. The former issue can be somewhat addressed by implementation. Things will never be perfect, but it all relies in the implementation. I believe the concept I proposed has enormous potential, especially to those offering web services to the campus. Why store public data in a limited access database when you can have the community collect and refine the data for you?

To those that doubt XML over HTTP as the true "web service" that scales to the Internet (and, as we all know, what works on the Internet today is for the Enterprise tomorrow), I give you piping content around the web with Atom. And, seriously, if you're still not convinced, you and I use two different Internets.