-
Notifications
You must be signed in to change notification settings - Fork 0
Open Data Reno platform #1
Comments
overated. |
Confused the hell out of me for a sec. |
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/ |
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? |
I would favor a multi-phase approach to dealing with our local data needs. Something like:
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. |
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). |
I wonder if we could leverage a GitHub organization... (And yeah, it's a stretch that anyone is going to care but us.) |
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.) |
@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. |
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. |
touche! + version control |
For the record, ANYTHING we do will be better than what we have. |
Let's take the twitter conversation off the 140 character limit :)
The text was updated successfully, but these errors were encountered: