Going Live! (by alaric)
But the fun part is how it works under the hood... the previous version of the site did the 'standard' thing of having a big, wide, table, with one row per listing, containing columns for the listing name, primary phone number, and so on. Which is rather limiting.
The new site, however, actually uses an RDF database. The contents of a listing, in other words, are stored as a series of logical statements about objects. "The listing holder's first name is Alaric. The listing holder's address's first line is '123 Any Street'". Et cetera. This lets us store arbitrary numbers of arbitrary types of objects in each listing, and store arbitrary information about each. It means that various object types - listing holders, locations, price lists, sets of opening hours - can share properties like 'title' (we use the Dublin Core title), and we can easily find any object in the system with a given title (or find the title of any given object), without caring about the type of the object. This kind of polymorphic data model gives us enormous power to do cool things easily. An object can easily have two 'overlapping' types, a facility we've not used in anger yet.
Plus, since we chose RDF as the data model (reusing properties from the Dublin Core, FOAF and other such standard vocabularies wherever possible), we open up the possibility of interoperability with the growing pool of third party RDF tools.
We need to do a little more to make things FOAF-compatible; in many cases, we needed a richer data model than FOAF and friends alone provide so had to do things differently, but when we get a moment we're going to make the publishing code also generate foaf-compatible versions of the data alongside the richer ones. For example, we allow a listing to have multiple locations then attach things like phone numbers to locations, which foaf tends to expect the foaf:phone property to attach directly to the listing owner object. So we have foaf:phone properties attached to the locations which are attached to the listing owner; so we must make our code output two foaf:phone properties for every entered phone number, one attached to the location and the other attached directly to the listing owner (and, thus, not specifying which location that phone number applies to, but being noticeable by FOAF tools).
Currently one can extract the RDF for a given listing with a nasty URL, but we'll soon have something a little less ugly in place, and linked to from the headers of the listing view pages with rel="meta". And we'd like to have an RDF import option at some point, allowing one to importing an existing FOAF file when setting up.
We also have a permissions system, whereby the RDF statements in the database may be assigned permissions; either public, private, or referencing a group of other site members who may see that information. This means you can use it to store private information, which you will see when you visit your own listing while logged in or with the editing interface; and you can use it to, for example, make your postal address visible to your friends, but not to the general public.
The search system is pretty neat, too; when you change things in the editor, it works on a 'staging' copy of your data until you elect to 'publish', at which point the staging copy is copied over the live data area for your listing, and the site analyzes the changed information to generate search keys, which are entered into a specially designed full-text index that can be queried without having to instantiate the RDF itself for every listing to do a search. The indexing process appropriately normalises and processes the listing's contents to convert them to a set of search tags that can be easily searched.
Wed 20th Dec 2006 2:06 pm 
Subscribe
By Alex Blok, Thu 28th Dec 2006 @ 3:12 am
Sweet service, I must join. 😉