Skip to content
This repository has been archived by the owner on Aug 7, 2022. It is now read-only.

Open Data Reno platform #1

Open
colinloretz opened this issue Oct 8, 2013 · 13 comments
Open

Open Data Reno platform #1

colinloretz opened this issue Oct 8, 2013 · 13 comments

Comments

@colinloretz
Copy link
Member

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

@supernullset
Copy link

overated.

@colinloretz
Copy link
Member Author

@jeremymurray
Copy link

Confused the hell out of me for a sec.

@aodin
Copy link
Member

aodin commented Oct 8, 2013

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
Copy link

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
Copy link

elskwid commented Oct 8, 2013

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
Copy link

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
Copy link

elskwid commented Oct 8, 2013

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

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

@jeremymurray
Copy link

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
Copy link
Member Author

@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
Copy link

elskwid commented Oct 8, 2013

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
Copy link
Member Author

touche! + version control

@elskwid
Copy link

elskwid commented Oct 8, 2013

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants