Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
foragemarkuplanguage [2010-09-09 19:32] 86.95.48.238foragemarkuplanguage [2010-10-27 10:39] (current) 145.50.39.11
Line 1: Line 1:
 ====Forage Mark-Up Language==== ====Forage Mark-Up Language====
  
-There are so many edible city/urban forage projects mushrooming all over the place, as the latest fad for artists, environmentalists and culinary types, I notice a certain perpetual reinvention of the wheel. All that data on where to find edible foodstuffs is locked-up in different formats usable only for that specific project. There is no technical reason why local data collected in Utrecht ([[http://plukdestad.nl/]]) 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 makes sense for local communities to maintain their own applications limited to a few streets or a neighbourhood. In fact territories as large as Utrecht (a medium sized cityalready seems much too big to faithfully map. Foraging takes time, knowledge and heightened awareness, it can't be done haphazardly. It makes sense to harvest local data and connect it with other data. 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/]]) or Bristol ([[http://duo.irational.org/food_for_free/]]) can't be dropped on worldwide maps ([[http://www.foodspotting.com/]], [[http://www.networkedorganisms.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. 
  
-What we need is uniform way of storing data that could be easily translated to other formats (KML/google map applications especially). I hear people talk about recording where what species can be foundadding to this layers  of information like the most likely time to harvest, what parts can be used and what parts not, recipes, medical uses, but also known problems with pollution and/or ownership in given erea. Some of these things should be includedsome of these things belong elsewhere.+Foraging takes time, knowledge and detailed understanding of an environment, it can'be done haphazardly. It makes sense for local communities to maintain their own applications limited to a few streetsa 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 '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 contributecritical mass needs a lot of initial mass 
  
-what follows probably already exists elsewhere but, just thinking aloud for my own funhere are some notes on quasi-RSS for foraging: FML: Forage Mark-Up Language:+What I seem to be saying is that the technical part has been solved many times, but that the social partthe creation of a good communityis lagging behind. As is only fitting for time still maddingly obsessed with the same old post-ice-age neolithical prejudices. 
  
-The first part (the channel tag in RSS) tells who is providing the data:+The need to share data we can all agree on. Different projects have different needs and objectives but we can all agree that plant name (latin and vernacular), location (gps coordinates) and time of observation are key, the name of the observer and a description field are useful. Other interesting factoids like taxonomic data, the most likely time to harvest, issues with food safety, recipes, medical uses, but also known problems with pollution and/or ownership in a given area could all be generated from this data from other (local) databases.  
 + 
 +Every project might try to solve the same problems (from a technical point of view) but they are all doing it using the same framework: google.maps. The data of the Urban Edibles Amsterdam website, for instance, can be downloaded as an RSS-file([[http://maps.google.nl/maps/ms?hl=nl&ie=UTF8&t=h&source=embed&msa=0&output=georss&msid=117889007389820522179.00045cc416710da996793]]) and this already solves some aspects of the problem, but with some loose ends. What follows is just me thinking aloud: 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 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> 
 +  <georss:pointtop>39.55375305703105 118.9813220168456</georss:pointtop> 
 +  <georss:pointbottom>35.55375305703105</georss:pointbottom> 
   <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> 
  
 The second part is a list of elements like these, each containing for each sighting the basic information The second part is a list of elements like these, each containing for each sighting the basic information
-concerning a plant/tree that should really be included to be usefull+concerning a plant/tree that should really be included to be useful
  
   <item>   <item>
Line 24: Line 30:
      <lan:eng>walnut</lan:eng>      <lan:eng>walnut</lan:eng>
   </plant>   </plant>
-    <location> +  <georss:point>52.326294 4.980637</georss:point>
-      <longitude>39.55375305703105</longitude>   +
-      <latitude>-118.9813220168456</latitude>  +
-      <altitude>1223</altitude>  +
-  </location>  +
-  <type>tree</type> +
-  <use> +
-      <edible>yes</edible> +
-      <medicinal>not known<medicinal> +
-      <fruit>nut</fruit> +
-      <poisonous>no</poisonous> +
-      <other></other> +
-  </use>+
   <picture></picture>    <picture></picture> 
   <observation_date>Tue, 22 Jun 2010</observation_date>    <observation_date>Tue, 22 Jun 2010</observation_date> 
   <observer>Little Chef</observer>   <observer>Little Chef</observer>
-  <description>old tree actively foraged by hungry, mandoline carrying, gypsies with bad temper and bad  breath</description>+  <description:eng>old tree actively foraged by hungry, mandoline carrying, gypsies with bad temper and bad breath</description>
   </item>   </item>
    
 +The plant tag collects names for the plant, the botanical name and the vernacular. The georss method is probably easier than the KML way of doing it: 
  
-The plant tag collects names for the plant, the latin is the botanical name, the others are 'normal' namesThe location tag is lifted straight from KMLThe use-tag collects properties about the plant/tree being tagged that might be useful for parsing. Some other relevant information like date of last observation ends it  +  <location> 
 +      <longitude>39.55375305703105</longitude>   
 +      <latitude>-118.9813220168456</latitude>   
 +  </location>  
 +  
 +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?  
 + 
 +-Discussion- 
 +[Joey] I think a markup language could indeed aid the data problem. But I would recommend some adjustments: 
 +1. maybe the tag plant could be changed to edible or species. Since there are related data collections which also mark edibles like fish or other non-plant like edibles/medicine 
 +2. I would expand the <picture> tag into a <media> container to support multiple media files (picture, video, perhaps even audio) 
 +Maybe even an optional further classification of the type of mediajpg,png,.mp4 ect. 
 +this would like like this: 
 + 
 +<media> 
 + <picture format="jpg"></picture> 
 + <video format="flash"></video> 
 + <audio format="mp3"></audio> 
 +</media>  
 +3. Also I would like to support the community aspect more. While the observer is describedit would like to also have further identification of the observerLike a personal page of id(facebook?) or just an url on the original foraging site. This way we can give credits to those who should get the credits. An in the future grand them special moderator or even admin rights according to their accuracy and/or amount of contribution 
 +So the observer tag could be like this: 
 +<observer> 
 +   <name>Little Chef</name> 
 +   <identification>http://www.boskoi.org/members/101031</identification> 
 +</observer>   
 + 
 +4. Last I would vote for the KML way of describing a location, since I seems to me easier to implement, and relying on spaces in xml is in my experience a possibility for a lot of errors.
      
-Just raving; there surely must be better ways to do itIF AT LLshould newcomers/outsiders be allowed to plunder the limited resources of a local communityOr publicize the existence of such resources+   
 +   
 +   
 +Joey: cheers, all fair pointsThe observer desires to be observered, also for trust-issues, maybe use <url> instead of description? or is that against best practise? For the media-tag though maybe just use<media>file.whateverextension</media> and let the parser figure out what it is and if to include it and how 
 +  It makes sense to broaden the tag from plant to species, but, on the other hand, only plants stay where they are, and the augmentation annotation model works because it localizes resources with extreme precision. Also, when you open up for all species you may want to inlude another tag to record plant, fish, tree of whatever.  
 +  an example file would be: 
 +   
 +  <item> 
 +  <species> 
 +     <latin></latin> 
 +     <lan:nl>walnoot</lan:nl> 
 +     <lan:eng>walnut</lan:eng> 
 +  </species> 
 +  <location> 
 +      <longitude>39.55375305703105</longitude>   
 +      <latitude>-118.9813220168456</latitude>   
 +  </location>  
 +  <media></media>  
 +  <observation_date>Tue, 22 Jun 2010</observation_date>  
 +  <observer> 
 +     <name>Little Chef</name> 
 +     <identification>http://www.boskoi.org/members/101031</identification> 
 +     </observer> 
 +  <description:eng>old tree actively foraged by hungry, mandoline carrying, gypsies with bad temper and bad breath</description> 
 +  </item>
  
 +  
 +   
 +  
 +  
      
  • foragemarkuplanguage.1284060731.txt.gz
  • Last modified: 2010-09-09 19:32
  • by 86.95.48.238