<div>Look: It seems to be debate about unstructured, semi-structured and structured data. What you're celebrating is something around semi-structured data.</div>
<div> </div>
<div>Marcus reminded my that OSM allows for a building to be more than just a shop, but a gas-station a fuel-station, lit, car-wash, etc. That's right, but keep in mind, that I *don't* propose to change the current internal OSM schema and I *won't* restrict the number of key on your side. I propose only to restict the character set of keys. I'm showing a use case where parts of the OSM data gets out into a usual application environment and I hope OSM was'nt meant to stick in it's free but "closed world". </div>

<div>
<p>So let's say for my application I'm happy with one attribute (type="shop") or two. You know that in a more application oriented environment you do stick to a schema with a distinct number of attributes and take care of each of them.</p>

<p>Having said that, if you want multivalued attributes and lossless data exchange there are many possibilities in my example schema to either sync' back based on the ID or store all the additional key/values you may receive from the users (e.g. in a attribute). This again to the prize that there is no usable index in the application schema (except for the ).</p>

<p>Rob wrote:<br>> You use building=shop in your examples but there is absolutely nothing<br>> to stop someone using (apologies in advance for my lack of language<br>> skills) construcción=almacén or ??????=?????.</p>

<p>Good example: How to make a map of more than one country when you an me can't interpret "construcción" and "??????" being buildings?<br></p><br><br> </div>
<div><span class="gmail_quote">2008/2/15, Jochen Topf <<a href="mailto:jochen@remote.org">jochen@remote.org</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Fri, Feb 15, 2008 at 12:57:41AM +0100, Stefan Keller wrote:<br>> model and will never evolve or be re-imported from other databases. Users<br>
> will be 'surprised' when they miss their data on the map like with 'Tunnel '<br>> instead 'Tunnel' or with things like that '¨name'='Südstrasse'. My proposal<br>> would eliminate that.<br>
<br>In OSM this problem is solved not by restricting what people can tag but<br>by having tools like the JOSM validator plugin and Maplint that will tell<br>you if there is data that "looks wrong" to the computer according to<br>
some criteria. It is the job of a human then to decide whether it<br>actually is wrong in his opinion and fix it. I expect these tools to<br>improve over time and eventually find most cases where people have<br>accidentally used the wrong tag. With this solution we keep the<br>
"default" openness: People who want to use unusual tags on purpose are<br>not restricted.<br><br>> Now obviously it's about "geographic data" as said in the OSM homepage and<br>> its about databases and it's hopefully not HTML. The model you choose it a<br>
> sort of meta model which is ok for initial capturing but not optimal for<br>> post-processing and showing it in maps - and the difference (from your point<br>> of view) is just restricting key characters to some smaller set!<br>
<br>Thats exactly what we are doing and want to be doing: We are capturing<br>data in the most flexible way possible. Everybody who wants to *use* the<br>data for something has to pick the subset of the data he is interested<br>
in and can convert it to any format he likes best and that is suited for<br>his needs. Of course there are ways to store subsets of the data in more<br>efficient forms and many people do that, but everybody has different needs<br>
and so needs different subsets of the data and in different forms. The<br>needs for somebody drawing a map are very different from somebody doing<br>routing, for instance. The OSM data model is not designed to be<br>efficient, it is designed to be flexible.<br>
<br>Jochen<br>--<br>Jochen Topf  <a href="mailto:jochen@remote.org">jochen@remote.org</a>  <a href="http://www.remote.org/jochen/">http://www.remote.org/jochen/</a>  +49-721-388298<br><br></blockquote></div><br>