Proposal talk:Libraries beyond books and multimedia

This is the talk page for discussing improvements to the Proposal:Libraries beyond books and multimedia page and its related topics.
Please sign and date your posts by typing four tildes ~~~~ at end of your messages. Put new text under old text. Click here to start a new topic. New to OpenStreetMap? Take a look at the Beginners' guide. Respect your fellow mappers. Be gentle, constructive, and assume good faith.

Is it necessary to separate Tool Library and Library of things ?

Let's discuss! From my point of view, the two concepts are relatively close and have the same kind of goals, but I'll argue that I didn't find any tool library which became a thing library and the first seems to also have in mind to offer workshop and education of how to use the objects.

It's almost inconsistent that library:material_type=tools;things or library:material_type:tools=yes + library:material_type:things=yes is suggested to be used, when amenity=thing_library and amenity=tool_library are separated. ---- Kovposch (talk) 07:37, 21 March 2021 (UTC)

They are different in that a Tool Library tends to house only tools whereas a Library of Things has a variety of items, but almost always includes tools among them. Shareuk (talk) 08:10, 31 March 2021 (UTC)

Styling

1. Avoid *type=*. At least use library:material=*. If the system is uncertain, a simple library=* or *_library=* will do for now.
2. Further to the above, I find  Tool library is included in  Library of Things at a glance. If you want to use *=things as a unspecific value, *:things=yes + *:tools=yes would allow more items to be specified in increment naturally. *=things;tools looks strange.
3. For conventional libraries, it will look misleading to only include *=tools or *=things on the amenity=library. Since it may be difficult to find a word to describe all traditional library items, using a *_library=* or *:things=yes added on top will be more systematic and logical.

-- Kovposch (talk) 07:58, 21 March 2021 (UTC)

On having subcategories

Note on previous trial (Old version with subtags and subcategories): after the first discussion on the tagging list, I tried to have more subtags like things="*" and tools=*" and have large possible values to tags, but I encountered some issues:

Problem 1: is having subcategories really making sense?

I tried to go the way of having subcategory for example for things, tools, etc. but it's very subjective and hard. And I'm wondering if it makes really sense. If we compare for example to a similar tag like clothes=* designated for shop=clothes or even books=* for library; those tags give information if the place has a specialty or not. For the library of things, having something similar like things=* make less sense as this type of amenities tries to get as much as possible items from different categories. Of course, I don't know the future and everything is possible.

Problem 2: boundaries between categories Also it can be hard to differentiate between things and tools. Random example: what is a printer?

Same problems for toys or games. The boundary between a game and a toy is even quite confusing: https://proto-knowledge.blogspot.com/2010/12/what-is-difference-between-toy-and-game.html

Problem 3: general categories and precise items I was more confident to find a list of category for example on Wikipedia, but to my surprise it's quite hard. I manage to have a good range of categories, let's say by kind of usage. It might be great for a tool library to know that they have the tool to repair a bicycle or for plumbing, but at the same time this is too imprecise and when should we define an amenity having such category. If a tool library only possess a rice cooker, can we say that it deserve the category "kitchen"? Surely not. Also, some items can be in so many categories, like for example ladders.

Imagoiq (talk) 20:00, 29 April 2021 (UTC)

Announcement of Voting missing

There was no announcement of the voting on the tagging mailing list (just to 'RFC' posts in May and June). --Mueschel (talk) 11:37, 20 June 2021 (UTC)

I followed the "Proposal process", and I didn't notice that the "Send (mailto link)" doesn't have the same subject as the text below – I'll fix that in the wiki. I propose, if you agree, to extend the vote end to 7 july and send another mail to the mailing list, please let me know if it would be ok. Imagoiq (talk) 12:47, 20 June 2021 (UTC)

Thanks for debugging and fixing! "extend the vote end to 7 july and send another mail to the mailing list" seems like a good solution to me Mateusz Konieczny (talk) 13:45, 20 June 2021 (UTC)

amenity=tool_library and shop=tool_hire

Is amenity=tool_library the same as shop=tool_hire? What are the differences? maro21 13:03, 20 June 2021 (UTC)

So from what I've found, there are no strict definitions, but here are the main differences from my point of view:

• Tool library are coming from the circular/sharing economy movement, are often community-driven project, associative and non-profit
• Fee might be per object, but some have also annual/monthly fee, and you can use as many tools as you want
• Not aimed at professional
• Some tool library have workshop to help you use the tool
• Tools definition go beyond than tools hire, for example: kitchen equipments, hobbies & crafts equipments, etc.

Imagoiq (talk) 13:17, 20 June 2021 (UTC)

Charge

The example use of charge=* does not follow its documented notation:

€20/year + €1/thing could be replaced by 20 EUR/year and 1 EUR/thing (or combined: 20 EUR/year; 1 EUR/thing). In this case a slight (and sensible) alteration would be needed for charge=* to add this syntax:

<amount> <currency>[/<person/item/etc.>][/<time unit>]

--JeroenHoek (talk) 08:52, 21 June 2021 (UTC)

I would consider tagging actual charge values in OSM a bad idea, like any business policies that can change from one day to the next. --Polarbear w (talk) 09:41, 21 June 2021 (UTC)

Same goes for opening hours, but this does not seem like the right place to propose deprecating charge=*. My point is merely that if people map those, they should follow the established notation. --JeroenHoek (talk) 10:06, 21 June 2021 (UTC)

opening hours tend to be significantly more stable than prices. --Polarbear w (talk) 10:37, 21 June 2021 (UTC)

Thanks JeroenHoek, I think I checked the page before you made so many changes (but welcome! It's much clearer, thank you). I think there are multiple schemas about those kinds of libraries:

• in some, you have annual/monthly fee + a price per thing
• in other, you can choose between:
  • annual/monthly fee + things are free
  • no annual/monthly fee + a price per thing
  • … and maybe there are other ones?

Can we describe all those situations? Imagoiq (talk) 18:23, 21 June 2021 (UTC)

Yes, I think so. charge=* is fairly young for a tag, and wasn't part of any proposal, so it is a bit on the open side in terms of its definition, but I think this follows existing use and the spirit of the tag:

• Annual/monthly fee + a price per thing: 3 USD/month; 1 EUR/thing
• Annual/monthly fee: 20 EUR/year
• No annual/monthly fee + a price per thing: 500 JPY/thing or 500 JPY/tool or even just 500 JPY

--JeroenHoek (talk) 18:48, 21 June 2021 (UTC)

About all the comments and opposition on voting

I'm not certain that it is allowed to comment during the voting process (I couldn't find anything in the Process proposal), but I would like to try to answer all the questions that arises, especially as I'm quite surprise and a bit disappointed that they only came during this phase.

I see two main trends of people against this proposal, but with the same idea. They want a more abstract tag either :

• To group those kinds of libraries into an "object-lending tag"
• To group all kind of libraries into the top-level tag library

At the beginning of the research, I tried to go this way, but other issues emerge:

• The issue of backward compatibility that everyone mention. This concern, I think, amenity=mobile_library and amenity=toy_library, which is rather limited. Does anyone have such experience with another tag in the past? Would it be feasible?
• Seeing those type of library as a collection of items/media/whatever. In one way, it would allow to simplify the description of a hybrid library, but having "things" which can be applied to anything make no sense. If you look at the | history of this proposal, you'll see that I even tried to have sub categories, but it doesn't solve anything really, and we would need to have a long debate to define what is a tool or a thing!
• Library of Things, Tool Library and Seed Library have reached a large audience. How can you match those term with an abstract tag? Looking at which items a library is lending, is not reliable, I think. First, as I said, you can find some handbook in tool library as well, so you'll have at least something like library:collection/items/media/whatever="books;tools". But this could be also the case of "standard" library. Secondly, If you look carefully at some examples of Library of Things and Tool Library, you'll see that categories might be a bit mixed. I saw many Tool Library lending sports equipment as well. So at the end, you'll need another sub tag to define what is the main purpose of the place.

Many critics are around the three concepts in themselves, and I mostly agree with some, but I think that we shouldn't have any discussion about those concepts. I thought that the idea of OSM is to map what you see, not redefining notions and or wrapping it in others. Or should we remove amenity=bar, amenity=pub, amenity=cafe and have amenity=drinking_place (please take it as a joke, more than a serious comparison)? I don't know.

In the concept of a seed library, I agree that it feel weird, and perhaps some answers are to be found at Wikipedia. The first one was actually called "Interchange Library". In the concept, it's not mandatory to bring back seeds (for obvious reasons), but it's well encouraged, but undoubtedly, it is strange to give back an item which not the same as the original. I'm not an expert, but the main differences with amenity=give_box are perhaps: the audience, the needed classification system and the fact that some also offer workshop around this thematic.

So in the end, I think JeroenHoek summarized well the situation; it's tricky. The main issue is certainly having an entity called "things". I don't see anyway for a general agreement, I'm just afraid that the topic'll fall into oblivion and to see no progress. Help is much needed! Imagoiq (talk) 17:05, 22 June 2021 (UTC)

On comparison amenity=public_bookcase and seed_library

I'm not sure, that to get all the concerns, but indeed a seed_library might be very similar to a amenity=public_bookcase and that's something missing in this proposal. location=* especially could be added. Is there any other tag that would be nice to add? Imagoiq (talk) 17:05, 22 June 2021 (UTC)