[Osmf-talk] Tagging standards

[steveaOSM]

On Oct 20, 2022, at 3:15 PM, Zeke Farwell <ezekielf at gmail.com> wrote:
> On Thu, Oct 20, 2022 at 5:31 PM Martin Koppenhoefer <dieterdreist at gmail.com> wrote:
> Am Do., 20. Okt. 2022 um 18:13 Uhr schrieb Zeke Farwell <ezekielf at gmail.com>:
> I wonder what those of you speaking out against tagging standardisation think about web standards?  
> 
> I don't think this is comparable. webstandards are like the editing API, nothing a normal user has to care for.

Let's be rather precise about how we linguistically describe these, I'll give it a shot here.

> I see many parallels between HTML and OSM data.

I do, too.  But while HTML + a browser that interprets these data produces "a web page" (like words plus proper syntax / grammar + a mouth and voice or + words on a page produces "a coherent sentence for a person who understands that natural language"), it takes OSM data + "something else" (a use-case, like "a renderer" or "a router") to produce "a map to look at" or "a route to take."  In the case of HTML + a browser, you certainly do need both:  valid syntax in your HTML representing content, and a browser to display ("grammatically utter") it.  In the case of OSM data, we frequently make the point that the OSM data stands by itself in a way different than HTML + browsers, because of our wish for these data to be used "in creative, productive, or unexpected ways."  Sure, most of the time, most people are going to use them in ESTABLISHED ways, like displaying them in Carto or cyclosm or whatever, or routing this weekend's snowmobile route because it is winter.  But OSM has that open-ended "you CAN" (and some people DO) invent clever and wonderful ways to "differently use" our data.  HTML as web data aren't (quite) like that.  Yes, "new browsers" get developed, but usually in conjunction with new versions of HTML, because "displaying HTML (web) data" is "displaying HTML (web) data."  I can see as Web 3.0 (and beyond) develop, this, too will get better (I imagine more 3D, VR, immersive, multiple-human-senses kinds of experiences), and so that aspect of "unexpected ways" happens with HTML + browsers.  But, over decades.  With OSM, people develop new methods (back-ends) for OSM data to get used creatively in weeks, months or years; turnaround cycle is faster than the Web.

Yes, for "nigh onto 30 years" we've been building both HTML as a language (a machine language, not a natural or human language, but a language nonetheless) AND various browsers to interpret these flavors of HTML.  HTMLs have evolved over many versions, the browsers have (necessarily), too.  Because of this, we have "the WorldWide Web," and "Web 2.0" and an emerging "Web 3.0."  All good, and I reiterate Zeke here.

>  It's true that a normal user doesn't care about HTML, much in the same way that a normal OSM mapper doesn't care about tags and just uses editor presets.

Yet, a major difference is that HTML, in any given incarnation of it that your browser claims to support, is NOT "open-ended" with regard to its syntax, while OSM most definitely IS "open-ended" like this, because OSM has "any tags you like."  That's a MAJOR difference.  So while Zeke is correct, Martin K.'s question (and perspective?) is valid, too, as "standardisation" (s or z, we know the word) is something that happens in conjunction with both the syntax (the data and its specific formats and structure) and the "parser" (a browser or renderer / router).  For HTML + browsers, these happen in a better-and-better-executed sort of "lock-step," where big software corporations and international standards bodies collaborate to develop, better-version and grow these into our future.  (Sure, sometimes there's an "upstart" browser which can be a bit disruptive, sometimes this is good, sometimes this ends up being effectively ignored as irrelevant; OK).  But in OSM, we have "any tags you like" plus a far more rapid development cycle of the "back-ends" (parsers, like renderers, routers and other end-use cases).  Notice I say "parserS" (plural), because while there might be small handfuls of (specific to an operating system, deliberately widely-supporting of MANY operating systems, localized to specific regions, optimized for certain kinds of hardware or screen sizes...) there are great many such back-ends for OSM.  And there should be, we want these, a major point of our project is to encourage this productivity / creativity to unleash the unexpected.  Well, development is "usually" pretty rapid, some things (like mapnik being effectively replaced by Carto) necessarily are longer-term, needing much more realtime feedback to achieve something approaching consensus.

So, these things (OSM and Web) are like each other, and they aren't, to various degrees.

> tagging standardization is like language standardization, telling you which words you should use when speaking and which distinctions shouldn't be done.

Yes:  there is a balance to be struck.  Use "what is standard" and be supported by "more" back-ends.  But you DO have the freedom of "any tags you like," and this helps to keep open the door to that hugely important tenet we have in this project to unleash creativity of the unexpected.  Again, when this not-always-easy-to-communicate dichotomy is well kept in mind, it can allow the proper "strict" vs. "wild" kinds of tagging behavior to be appropriated in a given context.  Sometimes you want to be perfectly standard.  Sometimes you want (or even need) to, in a sense, "invent your own language."  If you are or plan on writing a renderer or router that parses such syntax, good for you, good for OSM and the greater world who can now say "ah-ha, we have a new, productive method to do or say or see something (mappable, geographic in nature...) where we didn't before."  OSM is both:  "map this standardly" and "you have an open canvas to be creative."  Please, let's keep that in mind, let's make that part of our culture, because it really is so.

> I've heard this often repeated, but that doesn't make it true.   Though it can sometimes seem like OSM has its own unique dialect of English, nobody speaks in OSM tags.  It's not that kind of language.

It's an artificial syntax for data that gets parsed by back-ends specifically tuned to geographically present a semantic presentation of the geo data we store in our database.  In a best case, these semantically represent real-world geo-data in "creative, productive or unexpected ways."  That's sort of a pipeline of language, like that "grammatical sentence uttered makes sense to the recipient" example of earlier, but you have to look at the whole pipeline, especially as you compare it to HTML + browsers.  ESPECIALLY as it is important to remember that HTML + browsers are fairly rigid (until they develop / evolve into new versions, usually knitted together rather tightly in many cases) while OSM (tagging + use-cases) is far, far more open-ended.  Regarding this open-ended nature (to quote Martha Stewart), "that's a GOOD thing."