Proposal talk:Toy library
Use of "public" as a key
This is probably a bad idea, even though public is not currently a key. The interpretation would be ambiguous anyway: does public=children mean that the games are for children or that only children are permitted entry (no adults may accompany children)? I'd say that the natural interpretation would be no adults are allowed to enter, not the intended meaning that there are no games for adults.
It would probably be better to use a form similar to that already used for social facilites, so toy_library:for=children, toy_library:for=adults, toy_library:for=all_ages.
Brian de Ford (talk) 15:53, 15 October 2018 (UTC)
Thanks for your input. You made a good point, although I don't think anyone would understand "public=children" as "no adults may accompany children" (I've never heard of any place with such a rule and I hope there is not).
That said, I like your idea and I changed my proposal to account for it.
--ChameleonScales (talk) 19:39, 15 October 2018 (UTC)
Organizations?
I already had tagged the place I know like this as amenity=toy_library, but re-reading the proposal I am not sure any more whether the tag applies. I am writing about a "ludoteca" (Italian word for toy library), which is kind of a kindergarten like place. Quite sure there are no adult games there. Kids go there to play and to be instructed in playing. There are quite some of these in my municipality, this is an official list (maybe not complete). One example I have heard of is called "Toy library and centre for psychological support of the parents", that's their website (There are also pictures of the place). Would this qualify for the tag? Is the availability of games a must, or are toys sufficient? Shall there be subtags for the availability of material? There are also clear rules, e.g. ages 18 month to 11 years, and parents. This could be easily expressed with the established tag min_age=* and max_age=*, people have to reserve a place because there is a maximum of 25 people admitted, etc. Does this proposal cover institutional toy libraries, or do they have to be private run by an "organization"? I would remove the word "organization", it excludes public toy libraries and private run "unorganized" ones. --Dieterdreist (talk) 16:22, 15 October 2018 (UTC)
To my understanding the organizations you mentioned qualify as toy libraries. You can have a look at the definition from the International Toy Library Association to be sure. And yes my proposal is open to all toy libraries (institutional or private) and I just changed my proposal to account for it. --ChameleonScales (talk) 20:19, 15 October 2018 (UTC)
- Are there any toy libraries that are run as for-profit businesses? If so, how should these be tagged? Maybe fee=yes? What about if membership is required? --Jeisenbe (talk) 03:48, 22 September 2019 (UTC)
Time to put this to a vote?
It's been nearly a year since this first appeared. The most recent change didn't really affect the proposal, just clarified how widely this is seen in the wild. Nobody objected to it recently, or had any useful input. I think it's time to put it to bed. Time to fish or cut bait. Time to move our bowels or get off the pot. Etc. The sooner we vote to approve it, the sooner the carto people can do something about it (or decide they won't). --Brian de Ford (talk) 22:10, 21 September 2019 (UTC)
- I plan to add some CC0 images to this wiki and submit my proposal to JOSM and other editors in the coming weeks. Should we wait for that before voting? ChameleonScales (talk) 02:35, 22 September 2019 (UTC)
- Adding images first is a nice idea. However, if you want to go for formal approval, it would make sense to do this first before requesting support from JOSM, iD and other editors. But if you don't feel it would be helpful to finish the formal proposal process, you could just request it to be added to editors, and then wait for more mappers to start using the tag before discussing adding the tag to Map Features and possibly to be rendered by various map styles. If you do decided to go for vote, it might be a good idea to send out another email to the Tagging list now, before opening the vote, to see if any new issues show up, and then vote in a week or two. --Jeisenbe (talk) 03:44, 22 September 2019 (UTC)
- I don't see much point to adding images. The toy library in my town is a building that used to be a shop with a crude sign "Cardigan Toy Library" in the window. I don't think there is a distinctive architecture (such as there is with many churches), so toy libraries are in random buildings. A picture of the inside won't really help mappers, and most of us know what toys look like anyway. You could ask editors first, but they often go by usage and/or approval: "Build it and they will come." Get it approved, then some people who want to map a toy library will find it on the wiki, see it's approved and use it. With enough use, carto and editors will pick it up (they may pick it up even with little use if they see merit in it). --Brian de Ford (talk) 12:14, 22 September 2019 (UTC)
- I don't see that adds anything not already covered by the wikipedia articles, but if it makes you happy then that's OK. Now can we have a vote? --Brian de Ford (talk) 13:21, 26 September 2019 (UTC)
Loan Key
I'm not a fan of the proposed key "loan=yes". First, the loan key doesn't seem to be in use anywhere else on Openstreetmap ( https://taginfo.openstreetmap.org/keys/loan ). So we'd be inventing something completely new. Secondly, does a toy library with loan=no even exist? Loaning out games is the defining feature of a toy library, much like loaning out books is the one of libraries. If a toy library wouldn't lend out games, it'd either be a childcare or a toy store. I propose that this part of the definition is cut before we move to a vote. Taktaal (talk) 13:09, 22 September 2019 (UTC)
- Since there are reference libraries which do not loan books it's conceivable there are toy libraries that don't loan toys but only allowed them to be played with on-site, but I'd class those as some sort of play centre/child-care centre. So I'd drop loan=no. If somebody ever comes across a place that calls itself a toy library but doesn't loan out toys, we could propose toy_library:loan=no, perhaps. --Brian de Ford (talk) 13:41, 22 September 2019 (UTC)
Definition
I fleshed out the description in order to explain it better to people who might come from countries where "Ludotheken" aren't much of a thing, and to give an explanation why existing tagging options are insufficient. I did this from a Swiss point of view. I'd like to verify if this description fits with how these places work in other countries there they are popular. Namely to check if these claims are true in a broader international sense:
- Are your toy libraries also mostly for children 6-12 years old (with some leeway a bit under and over that age)?
- Do some of your toy libraries also allow onsite playing, but don't really offer much supervision, differentiating them from a childcare?
- Are toy libraries for adults also pretty much unheard of?
Taktaal (talk) 13:18, 22 September 2019 (UTC)
‘Disabled’
I have concerns about the sub-qualifying tags to describe admitted visitors as they don’t describe what you can actually find on site. It’s unclear if tags like …for:children and for:disabled are exclusive or not, and for:disabled isn’t helpful at all if there is no description of the available services or facilities. Does for:disabled and for:children mean that the service is for disabled children or for people with a disability _and_ children? Does for:disabled mean that there is an accessible service for me if I have any kind of disability? Does it mean the staff members speak sign language? Do they know how autism works? Is there a site map in plain language? Is the entrance accessible with a wheelchair? All of this is implied by the tag. A visitor expecting tactile toys for blind people could be disappointed if a place tagged …for:disabled only offers toys to train visual perception for non-blind children, for example. Please describe the physical, observable world, don’t classify people!
Imagine an app that would make use of …for:disabled. Which app would that be and why would a disabled person open it? Should an app like Wheelmap or Blindsquare display places with …for:disabled as accessible, and why/why not?
If your intention was to help people with disabilities, it would be better to talk to people with different kinds of disabilities and ask them about their specific needs, then introduce additional tags that work better and describe the available services and physical reality.—Preceding unsigned comment added by Hypo808 (talk • contribs) 16 October 2019
- I'd see the proposed *:for tag as a way to generally sub-tag the target group. The value list is typically not limited to the initial proposal, and will adjust to what exists in reality. Thus, if there are indeed such facilities and the argument is not just hypothetical, the mapper can easily qualify *:for=blind or *:for=deaf or *for:autist. Also, semicolon-separated lists are common for such sub-tag. For wheelchair access there is an established tag already. Many tagging discussions I have seen recently try to press the world, which has a continuum of values, into a too rigid scheme, just to find there are always exceptions. Any visitor would avoid disappointments by contacting the facility before visiting, if looking for a particular item.--Polarbear w (talk) 09:18, 17 October 2019 (UTC)
- Background: I maintain accessibility.cloud and Wheelmap, a well-known app that uses OSM's wheelchair tags. Sozialhelden, the NGO that created Wheelmap, is a voice for people with other disabilities, too. Over the last years, we have learned from working with over 100 APIs/standards that describe physical accessibility attributes of all kinds to draft a harmonized new standard, A11yJSON. Declaring 'Place X is accessible for people in category Y' in a data set is a typical mistake that leads to unusable data and additional barriers for people that identify themselves as being part of category Y – we even wrote about this problem in A11yJSON's documentation. The wheelchair tags kinda (!) work for wheelchair users, because most wheelchairs and wheelchair-accessible toilets are standardized and have measurable, physical attributes. wheelchair:yes declares that a space is compatible to these attributes. For other disabilities there is no such simple standard though: If you are diagnosed with autism, this can mean you need your surroundings to be quiet. A toy library isn't necessarily quiet. In which cases should the tag *:for=autist be used then? If it gets (re-)defined, how can you maintain data quality? While there is no metric to measure 'accessibility for autists', environment noise levels and presence of toy categories are measurable, save everybody from arguing about continuums, and don't lead to wrong expectations. And why should disabled people have to contact a place before they can go there? The wheelchair tag's purpose is that you do _not_ have to do this anymore! It should be the same for the toy library tag. I'd oppose the *:for=disabled variant of the tag and move this to a new proposal based on the recommended physical facilities listed here so a to-be-existing app specialized on this topic can actually make use of the data. --Hypo808 (talk) 13:23, 17 October 2019 (UTC)
- I appreciate your effort and look forward to your proposal to tag the environmental conditions related to various disabilities. The *:for=* tag proposed here is probably not suited for this, as I understand it means more what primary collection of items the facility provides. --Polarbear w (talk) 22:16, 17 October 2019 (UTC)
- Background: I maintain accessibility.cloud and Wheelmap, a well-known app that uses OSM's wheelchair tags. Sozialhelden, the NGO that created Wheelmap, is a voice for people with other disabilities, too. Over the last years, we have learned from working with over 100 APIs/standards that describe physical accessibility attributes of all kinds to draft a harmonized new standard, A11yJSON. Declaring 'Place X is accessible for people in category Y' in a data set is a typical mistake that leads to unusable data and additional barriers for people that identify themselves as being part of category Y – we even wrote about this problem in A11yJSON's documentation. The wheelchair tags kinda (!) work for wheelchair users, because most wheelchairs and wheelchair-accessible toilets are standardized and have measurable, physical attributes. wheelchair:yes declares that a space is compatible to these attributes. For other disabilities there is no such simple standard though: If you are diagnosed with autism, this can mean you need your surroundings to be quiet. A toy library isn't necessarily quiet. In which cases should the tag *:for=autist be used then? If it gets (re-)defined, how can you maintain data quality? While there is no metric to measure 'accessibility for autists', environment noise levels and presence of toy categories are measurable, save everybody from arguing about continuums, and don't lead to wrong expectations. And why should disabled people have to contact a place before they can go there? The wheelchair tag's purpose is that you do _not_ have to do this anymore! It should be the same for the toy library tag. I'd oppose the *:for=disabled variant of the tag and move this to a new proposal based on the recommended physical facilities listed here so a to-be-existing app specialized on this topic can actually make use of the data. --Hypo808 (talk) 13:23, 17 October 2019 (UTC)
- There's a bit of an overarching issue that is probably a bit out of scope of the discussion on a single tag. On one side, these "for" tags are always too general and never adequately describe what can exist in the real world. On the other side, they are also very badly maintained, in that the absence of such a tag can never be taken as an indication that a specific service does not actually support something. Making the tags even more granular just exacerbates that second issue. I added the tag because of a request during the RFC step and I figured it'd make sense to add an indication that a "for" key would be allowed. The OSM editors do not enforce the value selection at all, so if there is indeed a toy library somewhere that focuses on toys for a specific subgroup then the editor that adds that place to the map could set that value. --Taktaal (talk) 13:58, 18 October 2019 (UTC)