OpenID and Wireless sharing

via Makenshi in #openid chat on Freenode IRC:

<Makenshi>: I found a wireless captive portal solution that supports openid.

With the newest release of CoovaAP, some new features in Chilli are demonstrated in combination with RADIUS to allow OpenID based authentication. (coova.org)

I’m happy to see this. It’s very close to some ideas I was discussing with Schuyler Earle and Jo Walsh some years ago around NoCatAuth, FOAF and community wireless. Some semweb stories may yet come to life.

At the moment, the options available for wireless ‘net sharing are typically: let everyone in, have a widely known secret for accessing your network, or let more or less nobody in without individually approving them. Although the likes of Bruce Schneier argue the merits of open wireless, most 802.11 kit now comes out of the box closed by default, and usually stay that way. Having a standards-based and decentralised way of saying “you can use my network, but only if you login with some identifiable public persona first” would be interesting.

OpenID takes away a significant part of the problem space, allowing experimentation with a whole range of socially oriented policies on top. Doubtless there are legal risks, big privacy issues, and lurking security concerns. But there is also potential for humanising interactions that are currently rather anonymous. In the city I live in, Bristol, there’s a community wireless effort, Bristol Wireless, as well as wireless Internet in countless local cafes. Plus commercial hotspots and whatever the city council are up to. Currently these are fragmented, and offer a variety of approaches. Could OpenID offer a common approach for Bristolians to connect? I like the idea that (for those that choose to ‘go public’) OpenIDs could link scattered presence across community sites. Having OpenID-based login used eg. for cafe-based access could be a nice step in that direction. But would people trust their local cafe to know what they’re doing online any more than they trust Google? Should they?

Data syndication

There have been various developments in the last week, via Planet RDF, on the topic of data syndication using RSS/Atom.

Edd Dumbill on iTunes RSS extensions; a handy review of the extensions they’ve added to support a “podcasting” directory. See also comments from Danny.

Nearby in the Web, Yahoo! and friends are still busy with their their media RSS spec, which lives on the rss-media yahoogroups list. Yahoo are also looking creative on other fronts. Today’s Yahoo! Search blog has an entry on Yahoo! Maps, which again uses RSS extensions to syndicate map-related data:

The Yahoo! Maps open API is based on geoRSS, a RSS 2.0 with w3c geo extension. For more information check out developer.yahoo.net/maps. We also offer API support via a group forum at yws-maps.

This is particularly interesting to me, as they’re picking up the little geo: namespace I made with collaborators from the W3C Semantic Web (formerly RDF) Interest Group.

Although the namespace was designed to be used in RDF, they’re using it in non-RDF RSS2 documents. This is a little dissapointing, since it makes the data less available to RDF processors. RSS1, of course, was designed as an RDF application specifically to support such data-centric extensions. Yahoo! have some developer pages with more detail, but they seem to have picked up where the Worldkit Flash RSS geocoding project left off. Worldkit attaches geo:lat and geo:long information to RSS2 items, and can display these in a Flash-based UI.

The WGS 84 geo vocabulary used here by Worldkit and Yahoo! was a collaborative experiment in minimalism. The GIS world has some very rich, sophisticated standards. The idea with the geo: namespace was to take the tiniest step towards reflecting that world into the RDF data-merging environment. RDF is interesting precisely because it allows for highly mixed, yet predictably structured, data mixing.

So that little geo namespace experiment (thanks to the efforts of various geo/mapping hackers, most of whom aren’t very far in FOAF space from Jo Walsh) seems to be proving its worth. A little bit of GIS can go a very long way.

I should at this point stress that the “w3c geo extension” (as Yahoo!’s search blog calls it” is an informal, pre-standardisation piece of work. This is important to stress, particularly given that the work is associated with W3C, both through hosting of the namespace document and because it came about as a collaboration of theW3C RDF/SW Interest Group. If it were the product of a real W3C Working Group, it would have received much more careful review. Someone might have noticed the inadquate (or non-) definition of geo:alt, for example!

I’m beginning to think that a small but more disciplined effort at W3C around RDF vocabulary for geo/mapping (with appropriate liasion to GIS standards) would be timely. But I digress. I was talking about data syndication. Going back to the Yahoo! maps example… they have taken RSS2, and the SWIG Geo vocab, and added a number of extensions that relate to their mapping interface (image, zoom etc), as well as Address, CityState, Zip, Country code, etc. Useful entities to have
markup for. In an RDF environment I’d probably have used vCard for those.

Yahoo aren’t the only folk getting creative with RSS this week. Microsoft have published some information on their work, including some draft proposals for extending RSS with “lists”. This, again, brings an emphasis back to RSS for data syndication. In other words, RSS documents as a carrier for arbitrary other information whose dissemination fits the syndication/publication model of RSS. Some links on the Microsoft proposal are on scoble’s blog. See Microsoft’s RSS in Longhorn page for details and a link to their
Simple List Extensions specification, which seems to focus on allowing RSS feeds to be presented as lists of items, including use of datatyped (and hence sortable) extensions.