To follow up on a thought I Twittered t’other day, picking up on a comment of Dennis Crowley’s: most public objects – and certainly all municipal objects – should offer APIs. (A concrete example: BART’s provisions.)
Furthermore, specifically with regard to public infrastructures like transit systems, I believe that this should be a matter of explicit government policy.
What’s a public object? A sidewalk. A building facade. A parking meter. Any discrete object in the common spatial domain, intended for the use and enjoyment of the general public. Any artifact located in or bounding upon public rights-of-way. Any discrete object which is de facto shared by and accessible to the public, regardless of its ownership or original intention. How’s that for starters?
5 Comments
To paraphrase J. Jacobs… API’s on the street?
See also Paul Hammond’s minimuni
http://www.paulhammond.org/2008/12/minimuni/
Minimuni doesn’t use an API – it scrapes the data, which more than doubled the development time.
As far as I can tell SF Muni don’t provide data publicly, although I assume they have a private data feed available to make things like Google Transit Directions possible.
This disparity is a little frustrating…
Paul, 511.org does have a data source for schedules. It’s not an API – more of a giant datablob you have to sign a release to see. I’ll e-mail more details.
The API versus the spitting out smarter data debate is one I can type out a whole essay on, but seeing as it’s almost 1 in the morning I just want to throw this out there:
If everything was meant to be played with then the connections between the data would have to be controlled by someone smarter than the system, the user. If everything had said something about what it did, then algorithmically one can take all data from all sources and come to a new conclusion that people sitting in front of a development environment would have never otherwise seen.
If you’re interested in public transit data sharing and APIs, I definitely recommend checking out the Transit Developers list:
http://groups.google.com/group/transit-developers
5 Trackbacks/Pingbacks
[...] Public objects « Adam Greenfield’s Speedbird "…most public objects – and certainly all municipal objects – should offer APIs. Furthermore, specifically with regard to public infrastructures like transit systems, I believe that this should be a matter of explicit government policy. What’s a public object? A sidewalk. A building facade. A parking meter. Any discrete object in the common spatial domain, intended for the use and enjoyment of the general public. Any artifact located in or bounding upon public rights-of-way. Any discrete object which is de facto shared by and accessible to the public, regardless of its ownership or original intention. How’s that for starters?" (tags: public objects everyware api infrastructure ubicomp ) [...]
[...] beta and a bit rough and ready in places, it is, perhaps, a glimpse at what could be possible when every public object has an API; when 10 neighbours have already told you about that local fire before the press have heard [...]
[...] it is well designed too. (tags: minimuni publictransport iPhone mobile travel transport locative) Public objects « Adam Greenfield’s Speedbird "most public objects – and certainly all municipal objects – should offer APIs" Amen to [...]
[...] Public objects · Adam Greenfield says that public objects – pavements, facades, parking meters, transport systems, or in fact ‘any artifact located in or bounding upon public rights-of-way … any discrete object which is de facto shared by and accessible to the public, regardless of its ownership or original intention’ – should have APIs. And he’s probably right. [...]
[...] Box, Gregor Wolbring and Simon Thompson have mentioned the need for a public API – James references Adam Greenfield here – which can allow users to do interesting things with their data, as well as supporting the [...]