[Tagging] Pet supplies store but doesn't sell animals

Sander Deryckere 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:
>
> shop=pet_supplies
>
> 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
>
> store=clothing
> men:bowties=yes
>
> Inventory changes, and this leads to increasingly bizare tagging of
> individual items.
>
> After all, why stop at "fish"
>
> animals:fish:neon_tetras=yes
> animals:fish:angel_fish=no
>
> ?
>
> 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:
>
> cuisine=thai
> menu:pad_see_ew=yes
> menu:pineapple_fried_rice=no
>
> We should be striving for simplicity wherever we can.
>
> - Serge
>
>
Please tell me what you think about it.


Regards,
Sander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20110612/96ac6086/attachment.html>


More information about the Tagging mailing list