| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| foragemarkuplanguage [2010-09-10 09:15] – 86.95.48.238 | foragemarkuplanguage [2010-09-10 10:19] – 86.95.48.238 |
|---|
| ====Forage Mark-Up Language==== | ====Forage Mark-Up Language==== |
| |
| At the moment I see many edible city/urban forage projects forming as the latest fad for artists, environmentalists and culinary types, but I notice a certain perpetual reinvention of the wheel. Each projects starts from scratch. There is no technical reason why local data collected in Utrecht ([[http://plukdestad.nl/]] in preperation) or Amsterdam ([[http://urbanedibles.blogspot.com/]]) can't be dropped on worldwide maps ([[http://www.foodspotting.com/]] and [[http://forage.rs/]]) or why old/dead projects can be imported as an initial dataset for a new project. It would be entirely in the spirit of such projects to share data, however all data is locked-up in different formats usable by project that generated it. A little active consideration on how to make this data shareable would do us all good. Perhaps, instead of kickstarting the same thing thousand times for a thousand little projects the edible city community could organize itself modularly. | At the moment I see many edible city/urban forage projects forming as the latest fad for artists, environmentalists and culinary types, but I notice a certain perpetual reinvention of the wheel. Each projects starts from scratch finding its own solutions. There is no technical reason why local data collected in Utrecht ([[http://plukdestad.nl/]] in preperation) or Amsterdam ([[http://urbanedibles.blogspot.com/]]) can't be dropped on worldwide maps ([[http://www.foodspotting.com/]] and [[http://forage.rs/]]) or why old/dead projects can be imported as an initial dataset for a new project ([[http://libarynth.org/augmented_foraging]]). It would be entirely in the spirit of such projects to share data, however all data is locked-up in different formats usable only by the project that generated it. A little active consideration on how to make this data shareable would do us all good. Perhaps, instead of kickstarting the same thing thousand times for a thousand little projects the edible city community could organize itself modularly. |
| |
| Foraging takes time, knowledge and a detailed understanding of an environment, it can't be done haphazardly. It makes sense for local communities to maintain their own applications limited to a few streets, a neighbourhood or a cryptoforest. In fact territories as large as Utrecht (a medium sized city) are already much too big to exhaustively document all its edible plants. But this is why the search and documentation is open to all you will say but if open source teaches anything it is the fact that a 'community of users' will not form around an empty product. The data must be rich to be meaningful and it must be meaningful for others to contribute, critical mass needs a lot of pre-input. | Foraging takes time, knowledge and a detailed understanding of an environment, it can't be done haphazardly. It makes sense for local communities to maintain their own applications limited to a few streets, a neighbourhood or a cryptoforest. In fact territories as large as Utrecht (a medium sized city) are already much too big to exhaustively document all its edible plants. But this is why the search and documentation is open to all you will say but if open source teaches anything it is the fact that a 'community of users' will not form around an empty product. The data must be rich to be meaningful and it must be meaningful for others to contribute, critical mass needs a lot of pre-input. |
| what follows probably already exists elsewhere but, just thinking aloud for my own fun, here are some notes on a quasi-RSS for foraging: FML: Forage Mark-Up Language: | what follows probably already exists elsewhere but, just thinking aloud for my own fun, here are some notes on a quasi-RSS for foraging: FML: Forage Mark-Up Language: |
| |
| The first part (the channel tag in RSS) tells who is providing the data: | The first part (the channel tag in RSS) tells who is providing the data and also a bounding box, this can tell parsers to ignore or include a file because its locations are outside of what it is looking for: |
| |
| <name>libarynth cookery department</name> | <name>libarynth cookery department</name> |
| <link>http://libarynth.org/</link> | <link>http://libarynth.org/</link> |
| <description>the plants in this list have been checked several times</description> | <description>the plants in this list have been checked several times</description> |
| | <location> |
| | <longitude:top>39.55375305703105</longitude> |
| | <latitude:top>-118.9813220168456</latitude> |
| | <longitude:bottom>35.55375305703105</longitude> |
| | <latitude:bottom>-115.9813220168456</latitude> |
| <language>NL</language> | <language>NL</language> |
| <pubDate>Wed, 25 Aug 2010 07:33:42 GMT</pubDate> | <pubDate>Wed, 25 Aug 2010 07:33:42 GMT</pubDate> |
| <location> | <location> |
| <longitude>39.55375305703105</longitude> | <longitude>39.55375305703105</longitude> |
| <latitude>-118.9813220168456</latitude> | <latitude>-118.9813220168456</latitude> |
| <altitude>1223</altitude> | |
| </location> | </location> |
| <picture></picture> | <picture></picture> |
| </item> | </item> |
| | |
| | The plant tag collects names for the plant, the botanical name and the vernacular. The location tag is lifted straight from KML. |
| The plant tag collects names for the plant, the latin is the botanical name, the others are 'normal' names. The location tag is lifted straight from KML. | |
| |
| Surely there are better ways to do it. IF AT ALL: should newcomers/outsiders be allowed to plunder the limited resources of a local community? Or publicize the existence of such resources? | Surely there are better ways to do it. IF AT ALL: should newcomers/outsiders be allowed to plunder the limited resources of a local community? Or publicize the existence of such resources? |
| |
| | |
145.50.39.11