hack4reno / archived-opendatareno

1 stars 0 forks source link

Open Data Reno platform #1

Open colinloretz opened 10 years ago

colinloretz commented 10 years ago

Let's take the twitter conversation off the 140 character limit :)

supernullset commented 10 years ago

overated.

colinloretz commented 10 years ago

https://twitter.com/SuperNullSet/status/387429081853087744

jeremymurray commented 10 years ago

Confused the hell out of me for a sec.

aodin commented 10 years ago

I like Will's idea of an "adopt a dataset" program. Building an API should be paramount, even (especially?) if that API only serves one resource.

As for building a platform, relevant xkcd: http://xkcd.com/927/

supernullset commented 10 years ago

I also like the adopt a data set program!

What about just using PG with the JSON datatype for everything? Are there limitations of this approach? Should the API be writable? How does one rebind the data? Is there one ring to rule them all?

elskwid commented 10 years ago

I would favor a multi-phase approach to dealing with our local data needs. Something like:

  1. Identify datasets (ongoing)
  2. Use the current open data site to bookmark these datasets
  3. Add the adopt-a-dataset feature (Love this idea!)
  4. Monitor which dataset generate the most interest
  5. Opt to convert static sets into API-like systems when interest is high enough or if the adoptive person wants to devote the time an energy
  6. Signify when these datasets become more dynamic
  7. Rinse
  8. Repeat

Ideally, we'd have a way for people to signify that they want the data in different formats and then encourage the communication back to the data providers.

supernullset commented 10 years ago

In regards to 4. I don't think that any dataset will generate enough interest. We are going to be in scratch our own itch mode for quite some time I expect.

Static datasets probably make some sense straight off. Each dataset can have its own thread around it discussing structure and identifying its base values(defined as those values which are not derived via computation of other values).

elskwid commented 10 years ago

I wonder if we could leverage a GitHub organization...

(And yeah, it's a stretch that anyone is going to care but us.)

jeremymurray commented 10 years ago

Static json files committed to github is a fine start. We have a few already. It may be good to add info on the data source straight in the file. (org URL, date pulled, etc.)

colinloretz commented 10 years ago

@aodin agree on the xkcd for sure. I don't think the datasets need to be standardized so much as they need to each have an adopter/maintainer and a doc. We store all the datasets in the same platform (postgres or mongo, what have you) with a thin web layer serving routes/queries and same format (JSON) but each has documentation showing what you need to get relevant data. For Property data, use opendatareno.org/washoe/property/xyz?param=123 or whatever it would be and then the developer can parse the JSON.

That way if its a straight static json file, we can actually hit an endpoint to serve up those files rather than looking at committed static json files in a github repo.

elskwid commented 10 years ago

GitHub gives you a link straight to a blob so static files have a built in end-point in a repo. Better that trying to roll our own.

colinloretz commented 10 years ago

touche! + version control

elskwid commented 10 years ago

For the record, ANYTHING we do will be better than what we have.