[Tagging] Proposal about suffixed tags has been approved

moltonel 3x Combo moltonel at gmail.com
Thu Mar 3 02:57:42 UTC 2016

On 25/02/2016, Hakuch <hakuch at posteo.de> wrote:
>>> That is absoulutely no justification for your edits without asking the
>>> the list.
>> I honestly believe I acted in the same way that you did (no accusation
>> of wrong-doing).
> sorry but that is is really far from truth. Before I did the changes,
> there was more than a month full of drafting a Proposal -> starting a
> RFC -> Voting. In the end of that process, we had a decision by voting
> 38:10.
> You cant compare this with you actions yesterday. You just ignored the
> proposal process and reverted the result just because you don't like the
> outcome.

The moral ground I'm standing on is that I was correcting the
erroneous conclusion that there was enough consensus to accept the
proposal. I know this looks like I'm pushing my singular viewpoint
against the community's, but there are a few points which should make
the current "official conclusion" feel uncomfortable, whatever your
personal preference on semicolon vs suffixes is.

In OSM we have to walk a difficult path between making the data
consumable without too many headaches and describing a complicated
world. Mappers have a lot of freedom and different solutions emerge.

For some choices, like jewellery vs jewelry, there's no value in
keeping both solutions so an expeditious decision is warranted.

For other choices like suffix vs semicolons, the list of pros and cons
prevents a clear winner from emerging. Luckily, both solutions can
coexist and there is no need to choose a winner. Actually, if a winner
is to be found, the community as a whole is certainly a better judge
than the tiny fraction of the community that we ([tagging] readers and
wiki editors) represent. Given both options, the community should
naturally (if slowly) converge to the supperior solution if it exists.
In a case like this, we'd need very strong arguments to say that a
specific popular solution should not be used...

...But those strong arguments were clearly lacking:
* Of the [tagging] participants who tackled the "semicolon vs suffix"
question directly (so not counting peripheral topics like the iD bug,
blanks and orderings, or comparison to lanes/opening_hours), many
(dare I say most ? in any case more than 20%) participants leaned
towards using the key rather than the value to encode multiple values.
* Various issues with semicolons that some consider show-stopers (like
litteral semicolons, or the 255 chars limit) were either ignored or
brushed aside as not relevant.
* The current usage statistics (hinting at the greater community's
opinion) that name_N is 10 to 20 time more popular than semicolons
[1], but this was again brushed aside (including the principle of
documenting current usage).

[1]: Using today's taginfo db dump:
sqlite> select key,count(*),sum(count_all) from tags where key =
'name_1' or key='name_2' or (value like '%;%' and (key='name' or
key='alt_name')) group by 1;
You can argue about the flaws of this simplistic query, but this won't
change the general result.

On 25/02/2016, Hakuch <hakuch at posteo.de> wrote:
> On 25.02.2016 01:37, moltonel 3x Combo wrote:
>> Firstly, there is a difference between documenting current practices
>> and advising for one practice over another. I did my best to remain
>> factual and to document but not advise, even if I secretly wish that
>> we stoped using multiple schemes and converged on one that had less
>> flaws than the others.
>> Secondly, while writing the MV page I did my best to summarize all the
>> opinions of the recent threads (even some I didn't fully agree with),
>> and my first email today was a way to ask people to join the
>> discussion.
> thats a problem of the wiki, that it is for doumenting as well as for
> advising. Thats a big problem for all unexperienced mappers and results
> in unsteady tagging. Thats why I ask you, to notice on the page that
> there are different positions. You even should link to the proposal
> because its also a document of the situation.

That's fair enough, any mention of the suffix and semicolon schemes
(for the name key as well as other keys) should also link to the
discussions, including the various proposals. I originally removed the
link to the "remove sufixed name-tags" proposal because it is IMHO
wrongly-accepted and because I was linking to the more factual "MV
tagging" page, but I'm happy to add links to the proposals and
discussions, as long as it is balanced.

>> If your proposal mentioned converting existing data as well as
>> removing its mentions from the wiki, it would have been more coherent.
>> Maybe I'm missreading things ?
> It is hard enough to do small steps :) Right, it would have been more
> coherent, but even much harder to get a workflow for this.

The proposal could simply have said that name_N should be phased out,
without planning the process. Without that, the proposal is just about
the wiki and not about the db, which is a bad idea. Without that, all
you can change in the wiki is remove mentions of name_N, but not say
that it is deprecated.

> Thats even
> one of the problems of this name_1 tags, you dont know what the name is
> meant for! So, how to retag the existing name_1 ? Very hard
> That shows, why it was important for me to stop this behavior and
> pushing people to use a uniform tagging scheme with semantic rich tags.

That's a strawman argument, you're talking about very different issues
here. According to your proposal, one would simply replace "name=foo
name_1=bar name_2=baz" with "name=foo;bar;baz" (or as some would have
it, "name=foo alt_name=bar;baz", whose proponents implicitly agree
that semicolons in 'name' are problematic, but then happily put a
semicolon in 'alt_name' where it magically isn't a problem anymore

The fact that we don't know wether the extra name is an old_name or a
loc_name or something else is independant of how the extra name was
taged. The information is equally lacking from name_1, name=x;y, and
alt_name. Do not shoot the name_1 messenger when it is just telling
you that the mapper didn't have nuanced information about which
context the extra name fits best in.

I didn't see anybody arguing against prefering semantically-rich
*_name tags when possible. The disagreement was about how to tag when
all else fails and we have multiple values for a single *name slot.

> I can't take responsibility when people dont read what is written in the
> proposal and what I said in the discussions again and again. I have got
> a problem with this iD behavior, but I did never think that the proposal
> will convince the developers of rethinking this feature. Thats why I
> verbalized it very soft "to pave the way"

You don't have to take responsibility for other people's misreadings,
but knowing about them should prompt you to take votes with a grain of
salt, instead of taking the tally at face value just because you like
the outcome.

If you want to take responsibility for something, how about the
superbly-onesided "Some points that came up in discussion" section ?

> however, you can start a discussion, draft a proposal, start a RFC,
> start a voting. When you are successfull, you can change what has been
> approved.

Discussing is what I've been doing all along (yes, the wiki changes
were just the continuation of discussion that I thought had ended).
But it's been draining, so I'd rather go back to actual maping and
coding for a while. If I come up with a perfect solution to the MV
problem, I'll make sure to share it. Until then, I'll only wake up
when somebody proposes again to get rid of a de-facto scheme despite
it being more frequently used and having less technical issues.

More information about the Tagging mailing list