Tom Raftery says BarCamp Dublin was excellent. 
Tom Croucher-Hughes has the write-up from last night's PowerPoint Karaoke. It was hilarious. Next time, y'all gotta come along. It's a riot.
Coda: Quick Review 
Coda, the new Panic web editor, goes a significant way towards web development nirvana.
Here are a few of the things I really like:
1. CSS. I can never remember CSS property names. Having a GUI editor for CSS rocks.
2. Built-in 'books'. Coda comes with guides to HTML, CSS, JavaScript and the PHP manual built in.
3. Tabbed interface. SubEthaEdit (my default editor) has a tabbed mode, but it's not by default. Unless you keep moving everything back to the tabbed window they start spawning everywhere. Coda keeps everything within the tabbed layout. Update: Dominik in the comments says there is a way of doing this. It's just the way I use SEE it doesn't do it that way. I'd love it if I could say "open all documents in one window only".
4. Customisable extension handling. My server handles "php" and "php5" files differently. Coda lets you set custom extension handlers so that if you open a "php5" extension, it'll still treat it as PHP. This is very helpful.
5. Validation. The HTML validator built-in is really sweet. I prefer how Oxygen validates - since it uses a schema, you can validate to any standard you like - but for straight (X)HTML, Coda is pretty damn great. Obviously, if you are doing tag soup HTML (put down the keyboard and look in to the benefits of XML...), then Oxygen won't validate that, but for anything XML based. When you put Coda in to standards mode, it'll prompt you with element and attribtue names.
6. The use of Clips. Clips store frequently used things - like DOCTYPE and XML declarations and basic page structures. This is quite neat and useful.
But there are things I'm not so wild about:
1. Preview mode. I've previewed a few things in there and they appear wildly different than they do in Firefox and Safari. I don't trust it's CSS rendering.
2. The CSS editor may encourage people to put CSS in their HTML rather than in a separate stylesheet.
3. There is currently no 'functional' mode as there was in SubEthaEdit. In SEE, when you opened, say, a PHP or JavaScript file, a menu would appear at the top of the window which you could drop down to reveal a list of classes and functions. This was very useful if you have a large class or large functions file. Update: Dominik in the comments says there is a functions list. It's in a funny place, but it's there and it works.
4. The price tag. I've already got a SubEthaEdit licence... 
It's great to see the Coding Monkeys and Panic work together on such a good product. I've never been a Transmit fan (Interarchy for me), but I love Coda.
eRDF list mode?
Keith Alexander has a great post on RDF-in-HTML. I agree with him on most of it. Here's an idea on how we could improve eRDF. I'm not sure how we would use this, but it would be basically eRDF with some extensions.
The key problem I have with eRDF is the lack of external subject support. If I could support external subjects in HTML, there would be tons more use cases.
The first extension would be called 'list mode'. The problem of external subjects (ie. subjects that aren't parent @id) can be solved with lists.
The semantics of this is quite sensible - a list is to contain a series of items. An outline is a list with a sub-list attached to one of the list items. Here's where it gets interesting. You could have the parent list item contain one 'A' element which is the subject for the sub-list items. You'd mark that up with a common class name.
This list would produce a triple giving 'Google' as the dc:title for google.com. Writing this is kind of a messy hack, but it would (a) be relatively easy to style, (b) not break the Don't Repeat Yourself design pattern and (c) validate. For styling, people could quite easily add non-'namespaced' classes to HTML. Some standard CSS patterns could evolve to cope with eRDF list data.
The other thing we could do is work at a block level.
See the code samples.
There are a few other things we can think about if we are sentenced to having what is basically a fairly ugly hack for embedded RDF - one of these is, well, reification. Yes, yes, it is useful, even if it's confusing.
Basically, I think we are in for a long wait while all the HTML, XHTML, W3C and WhatWG people stress out at each other over HTML standards. But the thing is, we shouldn't have to care. RDFa adoption isn't going to happen until XHTML is a reality. I haven't got time to wait for that to happen, and I can't put off embedding external subjects.
As for rdfs:label triples - we can sort that out by modifying the XSL. A GRDDL processor could look for the profile declaration and override if it doesn't want rdfs:label.
Before I get the usual crowd saying that I should just STFU, let me just say this: this is a temporary hack. It fits within the vision of GRDDL. And we'll make sure that all the cool stuff like microformats still works.
I see no real problem - so long as GRDDL stylesheets are provided - why we can't have multiple RDF-in-HTML formats. I think we ought to use GetSemantic to draft a modified version of eRDF. I just haven't got time to do it at the moment.
Tags: semantic web, erdf, rdfa, grddl, semanticweb, xslt, microformats
Semantic Web FAQ
The Semantic Web Education and Outreach Project have put out the Semantic Web FAQ. It's a good resource. You should read it.
That's not to say it's perfect. Here's a part I disagree with (section 2.6 - 'How does the Semantic Web relate to tagging, folksonomies?')
Tagging has emerged as a popular method of categorizing content. Users are allowed to attach arbitrary strings to their data items (for example, blog entries and photographs). While tagging is easy and somewhat useful, it destroys a lot of the semantics of the data. In the Semantic Web, instead of tagging data items with strings, they can be related to other resources which can be uniquely identified, like ones representing people and places. The relationships are very specific, like who took the photograph, who is in the photograph, where the photograph was taken.
I don't agree that tagging does destroy semantics. It is a useful stepping stone towards richer semantics, because the default state is no semantics. There are lots of places where tagging is limited and other approaches might be better suited, but for a lot of things tagging is very useful.
As a result of reading this, I discovered Semantic Radar, a neat looking Firefox plugin.
