[Tagging] Pet supplies store but doesn't sell animals
sanderd17 at gmail.com
Sun Jun 12 09:04:21 BST 2011
What about this tagging schema:
shop=pet_supplies for shops that don't sell pets
shop=pets for shops that do sell pets, and if you want to go in detail, you
can tag it
animals=fish;dog;cat;horse;whale (or in the plural form if you like to)
While you can give it the same amount of detail, it has some advantages:
2011/6/12 Serge Wroclawski <emacsen at gmail.com>
> I'll elaborate on why this is a bad idea:
> 1. It's a lot of tags
> Not anymore, it's one or two tags, depending on how specific you want to be
> The problem with over specificity is that in my experience, it scares
> mappers off.
> We want users to come in and be able to map quickly and easily; but
> what we see from a subset of our community is the desire to design
> complex hierarchies of tags. These tags intimidate users.
If a user does not want to edit the animals list, he doesn't have to. It's
only one tag extra.
> 2. It won't get used in real life
Maybe not, but if someone likes to use it, he can.
> The second problem with these complex scheme is that the tagging list
> is an entity unto itself. People on this list love specificity, they
> love the idea of mapping in extreme depth. The problem is that it's
> rare that these tags get used. The original mapper uses them, maybe a
> few others, but overall they're just noise in the data, but appear
> prominently in the documentation. See #1.
It won't appear prominently, only in the description of the tag "shop=pets".
> 3. It's nested
Not entirely nested any more, you don't have the ':' structure.
> In the Python programming world, there's a saying "Flat is better than
> nested."- I feel the same applies to tags. In this example the
> question was "Can we distinguish between pet shops that sell animals
> and those who don't."
> My suggestion was that the term is ambiguous, but if you wanted to
> make them less ambiguous, you could distinguish a pet supply store by
> simply having a tag:
> That's simple, easy, elegant, and solves the problem.
> if you wanted to have an animals=yes tag, I'd /almost/ be okay with that.
I don't like *feature=yes* tags, if you have a feature key, the value can be
used to describe it, putting "yes" is kinda useless IMHO.
> But when you start getting into these nests and subnests, I think this
> is an exercise in complexity and futility.
> 4. It's apt to change
> The value can change (like any value) but the keys won't change.
> animals:fish = yes is you listing a store's inventory.
> It would be the same as
> Inventory changes, and this leads to increasingly bizare tagging of
> individual items.
> After all, why stop at "fish"
> 5. It's outside the reasonable scope of the project.
Maybe, but if someone wants to map it, he can.
> There's value in knowing what store carries what product, but it's not
> OSM's job to do that tracking.
> In some cases we bend the rules a bit, as you mention in your fuel
> example, or as I sometimes do with cuisine= on a restaurant. That's
> why I'm okay with the distinction between pets and pet supplies, but
> where I'm not okay with listing individual items of the inventory any
> more than I would be if we had:
> We should be striving for simplicity wherever we can.
> - Serge
Please tell me what you think about it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging