http://talklikeapirate.com/err404.html

It is always good to support the underlying message of the site.

Andrew.

“The developers over of the BBC site Programmes have supported semantically marked up data ( in the form of Microformats ) from day one. Now comes word that because of certain decisions made during the design of hCalendar and its use of the abbr, they are removing hCalendar support from the Programmes web site. Other Microformats being used will remain ( rel & hCard ). However, developer Michael Smethurst has hinted that the Programmes team might migrate over to RDFa and remove all Microformats. This is the first instance that I have heard of where a team will be moving away from Microformats and possibly embracing RDFa.”

http://www.oreillynet.com/xml/blog/2008/06/bbc_microformats_and_rdfa.html

The BBC itself says: “You MAY use microformats on your site where there are agreed, not draft, specifications (refer to the Microformats community wiki site for details) with the exception of those that use the title attribute of HTML’s abbr element.”

http://www.bbc.co.uk/guidelines/newmedia/technical/semantic_markup.shtml

On that, I’d be interested in seeing what you think of the way the Beep ’standardise’ microformat use (as per above link). And any thoughts on RDFa?

cheers

The idea of incorporating them into the New Zealand Government Web Standards is a good one. Encouraging agencies to publish a core feed is an excellent way of getting people into the game.

This kicks off a wider discussion around the general state of public sector websites.

To quote Matthew “Publishing only web pages is not good enough anymore.” That really resonated! And yet, that’s what we continue to do. Too often, valuable information languishes on websites. The data is “dumb” and users can’t interact with it at all.

A standard for government feeds is a good start. But really we need to be exposing government data more widely and in a number of ways. Matthew has talked about iCalendar and hCard on this blog for instance.

Well - I would like to see more of *that* in the Web Standards. Please

The agency/website should publish a core feed meeting the following requirements:

• Machine discoverable from the home page (DNS root)
<link rel=”alternate” type=”application/atom+xml” …

• Human discoverable from the home page (clear labelling)

• Atom format (see Feeds spec…)

• Publish all new/changed items for at least the previous 7 days (to ensure continuity for aggregators/readers)

• Publish all (website) items as far as possible. (including news, consultations, reports, alerts, media releases etc. Probably not specify categories.)

• Publish the full content of each item (as opposed to a summary with a link). This is important for many reasons:
– for accessibility - users can easily access item content independent of the web site
– for offline viewing - feed readers can load the feed content for later viewing offline (for commuters, slow rural connections etc)
– for mobile devices - mobile readers are optimised for loading and displaying feed content
– for speed/usability - reading full content is much quicker than following a link to the source website
– for mash-ups - full content is required to enable manipulation for unforeseen uses

• Times should be specified in the NZ zone +1200.

Maybe the answer is that agencies need to do both? Publish a core feed of all their content, suitably tagged and categorised, and then a minimal set of filtered feeds? If we are doing one, then the other is not that much extra to do. That serves both purposes — aggregation across government, and specific user interests.

There is of course the issue that some agencies will face (no names mentioned)……. all of the above discussion is assuming that they actually will be able to generate the necessary output from their various CMS / publishing systems…

I agree that the web standards have a role to play.

Another random thought Ive just had — would be worthwhile doing some thinking about how agencies could effectively track and measure traffic generated by consumption of the feeds — be an interesting evaluation exercise to demonstrate growth in traffic simply by exposing content via a feed.

1) I totally agree. Publishing only web pages is not good enough any more. It really doesn’t count as open government information - we must be implementing the better solutions which exist now.

This is an important message that needs to be spread. How? The NZ Web Standards probably have some role to play. There probably needs to be plenty of ‘carrot’ too… my vision is to demonstrate the power of personal aggregation and thereby encourage agencies to publish to feeds.

Imagine a simple my.govt.nz which could take some profile details and deliver relevant information by filtering on category and source-agency…

I’m also working with the the portal newzealand.govt.nz to enhance the exposure and status of the main government feed (aggregated from all govt sources).

I’d like to think that fuller, better tagged feeds and the agile services that can be built from them can deliver rapid transformation in opening up government information.

2) In the proposal, the category list is not intended to be a fixed value list, but rather a set of values with a prescribed meaning that can be used in conjunctation with other ‘tags’.

This is only partly with the portal and its specific functions in mind. It’s really just a first cut at suggesting how to tag information into usable segments. In the long term, no doubt a true folksonomy will develop.

>As a consumer of these types of feeds I personally wouldnt want to have all sorts of information jumbled up into a single feed.

At root government level, I disagree.

I think the first challenge is to get _all_ of the data exposed. If this was to be through multiple feeds, then likely a feed-of-feeds would be necessary to ensure that all individual feeds were discoverable.

As the primary goal, let’s get agencies publishing a core feed! With a core feed in place and suitably tagged, users or 3rd party tools can easily filter their own view.

Secondarily, agencies may well then also choose to deliver ‘pre-packaged’ filtered feeds - subsets of the main feed. Something close to this is already happening at the Beehive, see
http://www.beehive.govt.nz/feeds

1) Should agencies be required to publish more information as feeds?
2) Whats the most effective use of the categorisation feature of ATOM feeds?

Here’s my 10 cents worth

*****

1) Should agencies be required to publish more information as feeds - such as reports, media releases, consultations, announcements and alerts, and other items that would be in the public interest — IMHO absolutely — I dont have time to trawl through the hundreds of government sites looking for new information — if its pushed out to me, I can filter out what I want to look at from the “background noise” — heaven forbid I could actually subscribe to some super feeds that aggregate results across agencies…..

*****

2) Whats the most effective use of the categorisation feature of ATOM feeds? Should agencies be using the category tag (which is not necessarily a controlled vocabulary) to indicate the type of document or service the feed relates to? Im not so clear on this one….

Is this just the mechanism the newzealand.govt.nz portal is using to differentiate feed content?

As a consumer of these types of feeds I personally wouldnt want to have all sorts of information jumbled up into a single feed. For example, if I want to subscribe to a collection of reports from an agency, maybe I dont want their media releases as well.

The example of the travel alerts is another great one — I travel overseas every now and then - being able to subscribe just to the travel alerts would be worthwhile - but surely I should be subscribing to a feed not a vast dump of information where I have to hope that the agency producing the feed has been consistent in its use of category terms? The categories in this instance could probably just refer to the geographic location and status of the travel advisory?

As I understand it, the ATOM specification does enable controlled vocabularies to be set for category terms - but given the limitations of other vocabularies like SONZ and FONZ — not sure this is a good idea. Which leads me to believe that the category tags should be treated as a folksonomy and agencies are free to choose the most appropriate terms they think describe their content.

If the portal requires us to separate feeds into different document or service types then different feeds is probably the most flexible and scalable? We could then require agencies to produce the minimum set of feeds and publish them in a consistent location?

*****

Also, on looking at the RFC 4287 specification there is an element for atom:logo and atom:icon - that are apparently not widely used, but can be considered part of the branding that can be applied to any feed. Has there been any thought around using either/both of these elements to add authority to the feed - and standardising the image(s) used? I don’t have a particular opinion one way or the other on this point.

Kind regards

Justin

(nice “prove you’re human” question)