A few months ago Ian Davis and I were chatting about some new approaches to helping practitioners climb the learning curve around Linked Data, RDF and related technologies. We were both keen to help communicate the value of Linked Data, share knowledge amongst practitioners, and to encourage the community to converge on best practices. We kicked around a number of different ideas in this vein.
For example, Ian was keen to provide guidance as to how to mix and match different vocabularies to achieve a particular goal, like describing a person or a book. Having a ready reference containing recipes for these common tasks would address a number of goals. He’s ended up exploring that idea further in the recently released Schemapedia. If you’ve not seen it yet, then you should take a look. It provides a really nice way to navigate through RDF vocabularies and explore their intersections.
The other thing that we discussed was Design Patterns. I’ve been a Design Pattern nut for some time now. Discovering them was something of a right of passage for me during my Master’s dissertation. I’d spent weeks revising and honing a design for the distributed system I was building, only to discover that what I’d produced was already documented as a design pattern in an obscure corner of the research literature. While I’d clearly reinvented the wheel, the discovery not only provided external validation for what I’d produced, but also neatly illustrated the benefit of using design patterns to share knowledge and experience within a community. Knowing when to apply particular patterns is a key skill for any developer, and the terms are a part of the design vocabulary we all share.
I suggested to Ian that we explore writing some patterns for Linked Data. Patterns for assigning identifiers, modelling data, as well as application development. We experimented with this for a while but ended up parking the discussion for a few months whilst other priorities intervened.
I recently revived the project. It’s pretty clear to me that there’s still a big skills gap between experienced practitioners and those seeking to apply the technology. I think the current situation is reminiscent of the move of OO programming from the research lab out into the developer community; design patterns played a key role there too.
Ian and I have decided to share this with the community as an on-line book, a pattern catalogue that covers a range of different use cases. We started out with about half a dozen patterns, but over the last few weeks I’ve expanded that figure to thirty. I’ve still got a number on my short-list (more than a dozen, I think) but it’s time to start sharing this with the community. The work won’t ever be complete as the space is still unfolding, it will just get refined over time.
You can read the book online at http://patterns.dataincubator.org.
The work is licensed under a Creative Commons Attribution license so you’re free to use it as you see fit, but please attribute the source. If you want to download it, then there’s a PDF, and an EPUB too. We’re using DocBook for the text so there will be a number of different access options.
I’ll stress that this is a very early draft, so be gentle. But we’d love to hear your comments.
Lost Boy 
Lovely! Thanks for writing this, and especially for an EPUB version. I’d love to see a link to the EPUB version someplace from the main book page; until I read your blog post I didn’t know it was available in that format.
Hi Leigh,
I really like the idea, and think the book is shaping up nicely. Well done, and thanks :-).
I think there is something worth saying more explicitly – ‘Cool URIs dont change’. In order to achieve stability in URIs its often a good idea to keep taxonomies out of the URI…..Your pattern ‘Hierarchical URIs’ doesnt necessarily make that philosophy explicit.
The fact that an episode of a programme can be used by multiple different brands or series is also why /programmes doesnt have the URI pattern /programmes/:brand/series/:series/episode/:episode
[where : is an identifier]
Even though there is a clear hierarchy of brand, series, episode, the fact that an episode can have many parents means that we shouldnt have parent terms in the URI – otherwise we risk having multiple URIs for the same episode and/or URIs that change as the brand title changes.
Hope this helps
C