Internet Alchemy

I think this is a revolutionary idea: a coin operated access point. Whoever thought this up is a genius. Forget having to have a contract with 5 different service providers, just put 2 quid in the slot and everyone in range benefits. With a simple business model such as the shop paying a monthly rental and keeping all the takings then these things should spread like wildfire.

Clay Shirky has fired a rocket at the relationship vocabulary. Here’s my polite response.

There are a number of themes in Clay’s post. The primary theme appears to be one of completeness: Clay’s thesis is that the vocabulary is incomplete because it doesn’t provide properties to model composite relationships: what if you are employed by a colleague you collaborate with?. Clay seems to be implying that he expects the terms to be exclusive. Of course they’re not. It’s perfectly meaningful to assert that Jane employedBy John and Jane collaboratesWith John. RDF supports this kind of assertion and you can also express it with the HTML method outlined in the vocabulary.

There is a second theme which is an accusation of hubris on the part of Eric and myself. By publishing a polished and updated version of a 15 month old vocabulary we have become as gods, able to control all manner of human expression. Clay suggests that the terms that we left out are somehow verboten. Of course it’s true that you can’t use our relationship vocabulary to say Jane gotArrestedWith John but the semantic web, as with all other forms of human expression is not limited to a prescribed list of verbs and nouns. The relationship vocabulary is no manual of newspeak, more a tiny copy of Johnson’s dictionary. There are many more dictionaries waiting to be written and some of them will allow you to say any or all of the things that Clay suggests he needs.

Maybe there’s a third theme here also: imperfection. The relationship schema is imperfect. Here we agree. The surprise is that Clay expects it to be perfect. On the one hand he says that relationships are messy to model and on the other he derides the vocabulary because it’s messy. Which is it to be?

Obviously I’m pleased that Clay has taken the vocabulary seriously enough to critique in detail. Somehow the thought that everyone would ignore it caused me more concern than the fear that everyone would hate it.

Despite all the obvious thought Clay put into his piece, he still managed to overlook the raison d’etre for the relationship vocabulary. Indeed it’s the raison d’etre for all vocabularies. Without these vocabularies, incomplete and imperfect as they are, we would be mute in the machine readable web, unable to express ourselves in any meaningful way. You only have to look at the etymology to realise that vocabularies give you a voice.

I’ve carefully stayed away from the Atom discussions for several reasons. Most of these are around the inaccessibility of
the original discussions which required permanent connectivity to participate. I’m also quite happy with RSS
which meets my needs right now. I’m planning to support Atom in myRSS when it’s more stable. Anyway, tonight I thought I’d take a look at the current syntax specification and was taken aback by the obvious overlap with Dublin Core.

Nearly every element in Atom is already contained in one of the DC specs. I took the time to compare the Atom elements with their DC equivalents and found something quite interesting: when you remove the overlap with Dublin Core what’s left is pure syndication.

The only elements that don’t have obvious conterparts in DC are those that deal with the syndication aspect of Atom, and to be honest there aren’t many of them: atom:feed, atom:info, atom:entry, atom:link, atom:content. So my question is this: why isn’t Atom defining a Syndication Element Set as a complement to the Dublin Core Element Set? Why duplicate all that effort when the Dublin Core people have been over the issues again and again for nine years? There are many people that I know are intimately familiar with Dublin Core who are involved in the syntax effort so why aren’t these elements being used. Is it NIH or something else?

Here are the Dublin Core/Atom correspondences:

atom:title - conveys a human-readable title for the entry
dc:title - A name given to the resource.

atom:author - construct that indicates the default author of the feed
dc:creator - An entity primarily responsible for making the content of the resource.

atom:contributor - construct that indicates a person or other entity who contributes to the feed.
dc:contributor - An entity responsible for making contributions to the content of the resource.

atom:tagline - conveys a human-readable description or tagline for the feed
dc:description - An account of the content of the resource.

atom:id - conveys a permanent, globally unique identifier for the feed.
dc:identifier - An unambiguous reference to the resource within a given context.

atom:generator - indentifies the software agent used to generate the feed
dc:publisher - An entity responsible for making the resource available

atom:copyright - conveys a human-readable copyright statement for the feed.
dc:rights - Information about rights held in and over the resource

atom:modified - indicates the time when the state of the feed was last modified
dcterms:modified - Date on which the resource was changed.

atom:link - The “atom:link” element is a Link construct that conveys a URI associated with the entry.
dc:relation - A reference to a related resource.

atom:issued - construct that indicates the time that the entry was issued.
dcterms:issued - Date of formal issuance (e.g., publication) of the resource.

atom:created - construct that indicates the time that the entry was created
dcterms:created - Date of creation of the resource.

atom:summary - construct that conveys a short summary, abstract or excerpt of the entry.
dcterms:abstract - A summary of the content of the resource.

Eric Vitiello’s relationship schema has a new home at http://purl.org/vocab/relationship/

Eric and I have been working together over the last few weeks to update this popular schema. We’ve fixed some issues and expanded the vocabulary to incorporate many terms in use by the social network engines. The main improvements are:

• A stable namespace for the terms in the schema: http://purl.org/vocab/relationship/
• A more comprehensive RDF schema incorporating appropriate OWL constructs such as symmetric and transitive properties.
• RDF and HTML representations for all individual terms in schema, e.g. http://purl.org/vocab/relationship/friendOf
• Many new properties to cover professional, personal and genealogical relationships.
• Examples of usage with FOAF and (X)HTML

The (X)HTML examples are quite interesting since they allow relationships to be asserted between the authors of pages using rel and rev attributes on links. This is similar to the XFN method but has the advantage of having an RDF interpretation and use of a unified vocabulary.

I’m looking at buying something like a Squeezebox as a replacement for having CDs lying all over the place. Is there anything else that’s similar out there that I can compare this with?

Update: I got the squeezebox and it’s even better than it looks online. The build quality is excellent and the user interface is intuitive. I’m now looking at buying two more - a wired one and another wireless. This is the future of home media.

The number one feature request in Pepys is arbitrary links in content. I’ve been working on this for a little while and it’s made me think quite deeply about the nature of the links in a Wiki.

Currently Pepys highlights WikiNames as you type providing you with the default Wiki linking behaviour. This is equivilent to typing a WikiName in the edit box of a Wiki page and hitting save. The page linked to is calculated from the WikiName itself. Deleting characters from the WikiName changes the page it links to. This is one of the elements of Wiki essence and enables serendipitous linking. The link itself isn’t a characteristic of the underlying markup but of the particular pattern match the application applies. Pepys doesn’t save these links when it writes out the XHTML but recalculates them each time the page is loaded or whenever the text is edited. This will let me show different types of links depending on whether the page pointed to exists or not.

Adding arbitrary linking introduces new behaviour: the link isn’t constructed from a pattern match but from a character range and the link may point to a fixed URI rather than being calculated from the linked text. Traditional wikis require extra syntax to support these types of links. Some let you add square brackets around any piece of text to make it into a WikiName. Others will let you include a URI in the brackets (often something like [<uri> link text]) which becomes the target of the link with the enclosed text becoming the link text. In Pepys, these sorts of links will be added by pressing a key combination, a toolbar button or selecting a menu item.

In Pepys, when you press CTRL + L (or select Insert Link from the menu) the currently highlighted text gets made into a link. The page this link points to is a function of the text you selected (removal of spaces etc) and it will change if you edit the text in the link. However, if you press CTRL + SHIFT + L (or select Insert Extended Link from the menu) a dialog pops up asking you to enter a URI. The highlighted text gets made into a link, the target of which is the URI you entered. If you edit the link text the link target stays the same. Because the user explictly requested a link in the page these have to be saved to the underlying XHTML somehow since their extent can’t be calculated at display time.

For Pepys, I’m calling links that calculate the target page from the text that makes up the link dynamic and those that keep the same URI no matter how you edit the text static. Additionally each link can either be persistent or transient depending on whether Pepys writes the link definition out to the XHTML. For persistent, static links Pepys will write out a proper anchor tag with an appropriate href attribute. Persistent, dynamic links are also written as anchor tags but I need a way to distinguish them from static links. The method I’ve selected is to write out an anchor with no href enclosing the linked text, like this: <a>link text</a>. Now, I’m not sure this is 100% legal, but I’m hoping it is since my only other alternative is to abuse another attribute such as class or rel.

In summary, links can be:

Dynamic and Transient

Traditional WikiWord links. No additional XHTML is written by Pepys. The link highlighting is performed by applying a pattern match to the text when it is displayed. The page being linked to is calculated from the linked text when the user clicks on the link.

Dynamic and Persistent

Equivilent to text being bracketed in a Wiki. Pepys writes <a>link text</a> in the XHTML. The page being linked to is calculated from the linked text when the user clicks on the link.

Static and Persistent

Equivilent to text being bracketed with a URL in a Wiki. Pepys writes <a href="foo.xhtml">link text</a> in the XHTML. The page being linked to is fixed.

Static and Transient

Unknown in the wild, which is unsurprising since the link disappears when the page is saved. Not supported by Pepys.

This is nearly complete in Pepys. The basic functionality is there, I’m now just working through all the interactions between the types of links, such as when the user inserts a persistent link overlapping a transient one. Not hard, but it means I’m making lots of fairly arbitrary decisions about behaviour which I usually try to avoid. When in doubt I invoke the principle of least surprise and take that route.

It’s been a few days since I implemented the SpamAssassin training and I can report that the experiment was a complete success. In fact I noticed a difference after the first training batch. Spam is back to manageable levels once more and any that does creep through get fed to the trainer. Double yum.

One warning though: when I redirected my first batch of spam to the spam collecting address I went through all my folders weeding out accumulated spam and found about 500 that were worth sending on. Unfortunately sending 500 emails in a short period of time triggered Pair’s spam filter and blocked me from sending any more mail! I had to offer up a grovelling apology to Pair’s sympathetic mail administrator! It’s a sad reflection on the state of email that we have to go through all these hoops and layers just to get to an acceptable email service.