Sunlight Labs has released a public API, their Sunlight Datakit. It’s a straight-forward, simple API for getting access to their Civic data, like Congressional Representatives, zipcodes, timezones, and some geographic information.

There is some basic information about elected representatives that makes politico mashups easier: the ability to tie a name to a state, the district and zip codes that they represent, their office telephone number, and so on. We have put together a simple labs “datakit” that does this for us, drawing from several publicaly available data sources. We are making this fully available and have provided a fully documented API for the methods we have developed for those sources. Find out about the datakit here.

Of course, any API needs a nice little client to tie it into your applications. Here is my Ruby client. It’s very simple, because is uses the fallback method_missing to handle any function passed to the class. This also allows the class to be extended by implementing specific methods if more processing of the response is needed.

require 'open-uri'
require 'rexml/document'
require 'cgi'
SUNLIGHT_HOST = 'http://sunlightlabs.com/datakit/'

class Sunlight
  def self.method_missing(service_method, *args)
    params = args[0].collect {|k,v| CGI.escape(k.to_s) + '=' + CGI.escape(v.to_s)}.join('&')
    url = SUNLIGHT_HOST + service_method.to_s + "?" + params
    open(url).read.split("|")
  end
end

resp = Sunlight.getDistrictFromZip5({:zip => 20740})
puts resp.inspect
  # MD:5
  # MD:4

resp = Sunlight.getRepresentativeNameFromCityState({:city => 'Detroit', :state => "MI"})
puts resp.inspect
  # Kilpatrick, Carolyn C.
  # Conyers, John  Jr.
  # Levin, Sander M.
  # McCotter, Thaddeus G.
  # Dingell, John D.

The Sunlight Datakit currently offers the following functions. Check out the documentation for information on the parameters and returned values.

• getDistrictFromZip5
• getStateFromZip5
• getDistrictFromZip9
• getStateFromZip9.php
• getRepresentativeNameFromDistrict
• getRepresentativePhoneNumberFromDistrict
• getRepresentativeRoomNumberFromDistrict
• getCityFromZip5
• getCityStateFromZip5
• getLatitudeFromCityState
• getLongitudeFromCityState
• getZipCodesFromCityState
• getTimezoneFromCityState
• getRepresentativeNameFromCityState
• getRepresentativeNameFromState
• getStateAbbreviationFromStateName
• getStateNameFromStateAbbreviation

It used to be just about sharing photos with friends, but now its so, so much more than that.

Flickr announces Machine Tags, (via Mikel) which is formal support within Flickr’s database and API for what are also known as TripleTags, namespace:predicate=value.

Example:

geotagged
geo:lat=43.245
geo:lon=-83.211


The idea was to add some specific meaning to a set of data (photo) in a way that was accessible to the user through the user interface. Savvy types would add keywords to the EXIF Metadata, but this is tedious, and this metadata is often stripped out when using some image conversion utilities for resizing/cropping/etc. Therefore, soon after the popularization of folksonomy, users found a way to also add ’semantic’ data.

However, this usage, while working, was not inherently supported. People used it as a way to find all their ‘geotagged’ photos, or photos of forests, and so on. But parsing them and dealing with them was sometimes a pain from the developer perspective, and it also made a mess of your tag clouds or tag listings as you had all these one-time-use tags for the specific lat/lon point.

Now that Flickr internally supports machine tags in a good way, developers can really start using this as a way to attach arbitrary metadata to any data item (photo, etc.) Dan Catt gives a good discussion on what it all means and how it can be used.

I wonder if a Microformats-like impromptu standards body will pop-up to help formalize the namespaces and predicates. Why ‘geotagged’ and not ‘geolocated’, ‘geo’, ‘geomarked’, etc? While free-form naming is nice - so very extensible, being able to use a common vocabulary would also be nice.

Perhaps just accomodating current standards and applying them to the machine tags would be good without requiring any additional work. I’m thinking like hcard:fn=andrewturner, hcard:url=http://highearthorbit.com, hcard:phone=555-1212, etc.

You the developer

So, the end result to the developer is to check out the additional parameters to the Flickr search method in the API. There is now a machine_tags optional parameter that allows you to search by namespace, predicate, or value and use boolean constructions for these parameters.

Dan Catt even references Spimes as an excellent example of why machine tags can really empower devices, especially sensored/automated ones. And now that Flickr has no limits on uploads, you can create frequent update-rate sensored images.

Leopard will officially support Ruby & Python bindings in Cocoa which is terrific news. I’m a big fan of interpreted languages when appropriate.

Of course, there are about a dozen other very cool technologies for developers in Leopard that should really make application development, faster, better, and more fun. I’ve gotten a chance to play some with Leopard previews, and the actual User-facing improvements are minimal. But what users will eventually get will be lots of better third-party applications. (via Theocacoa and Michael McCracken)

It’s great to see how much effort is going into not just creating slicker UI’s, but better supporting the people that really make or break an operating environment - developers. Microsoft has had a lot of developer support for quite awhile, and I constantly hear about various .NET meetings/presentations/technologies etc. Apple really kicked it off by releasing XCode for free (no ‘professional versions’ need apply) and then having terrific Developer Documentation and examples.

The Leopard developer page makes some odd claims:

Mac users love to exchange quick messages, have video conferences, and collaborate on each other’s desktops across the network.

um… right, ok. I just love collaborating on your desktop. Anyways, I can’t wait to dive in and start developing on Leopard.

On Wednesday at the SouthEast Michigan Ruby Brigade I gave a ‘lightning talk’ on Ruby & Hardware. It is a quick succession of slides (written using S5) on some of the cool hardware devices you can control with Ruby, or hardware you can control your computer with.

It has includes examples and links to using Ruby with:

• NabazTag
• Symbian Mobile Phones
• Nokia 770
• Roomba vacuum cleaners
• Apple Remotes (the kind you get with your MacBook/MacMini)
• SlimDevices SqueezeBox and SlimServer
• Lego Mindstorms NXT

There are definitely more devices out there that can or should work with Ruby. Given ruby-serialport it’s possible to control just about anything.

I talked a little while ago about the enlightening insight of understanding more about how the next phase of Applications will be “desktop-deployed web applications”. This was inspired/aided by listening to the brilliance of people like Matt Webb. Using standardized, hopefully cross-platform technologies, it’s possible to develop your application once, and “push” it to any number of devices.

Ajaxian discusses Adobe’s new “Apollo”:

Apollo is client-based software that will run Flash applications separately from a browser, whether online or offline

The image shows an example travel application developed in Flash, and deployed to a desktop via Apollo. (via Digital Backcountry)

I also saw that Chris Messina is helping out on a project WebKit on Rails, whose goal is to make it easier to deploy Apple’s WebKit and also to “come up with new ideas and practices that leverage the WebKit platform”. WebKit is an excellent platform to develop desktop web apps, as it can be baked straight into a Cocoa application, but be accessing a “web application” that may be running locally on the users’ machine.

rails-app-installer allows you to bundle and install/uninstall a Rails application, including required gems.

$ gem install my_app
$ my_app install /some/path