- From: <chaals@yandex-team.ru>
- Date: Mon, 22 Sep 2014 12:52:13 +0200
- To: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>, "ding c. (cd8e10)" <cd8e10@ecs.soton.ac.uk>
- Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
20.09.2014, 10:21, "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>: > Hi all: > > When we build extensions for modeling accessibility, we should already have the need for a future real estate and accomodation extension in mind, i.e. modeling buildings. It would be bad if we model building features differently for accessibility and for real estate offers. Indeed. One of my reasons for making something really simple and really clearly experimental is to gather a range of feedback both in terms of things we are missing, and hopefully in terms of how stuff gets used in the wild (the problem with a lot of vocabularies is that they have been developed by a small community, and it is hard to predict what parts of them will be used effectively by a global community who don't have shared perspectives and history). The other is to make it so clear that there are problems that we really will have to make a revision within six months to a year… (Which leads me to the question - do people support releasing the very minimalist test we have, as an experiment, or do others think we should start with a larger more detailed vocabulary?) cheers Chaals > Martin > > On 19 Sep 2014, at 16:04, ding c. (cd8e10) <cd8e10@ecs.soton.ac.uk> wrote: >> Hi Chaals, >> >> Thank you for your email. The issue you proposed in your previous email is actually the issue of my Phd looking for. Accessibility is the kind of complex issues due to the different challenges faced by different individual. Therefore, a proposed idea is using some vocabularies to present the metadata of accessibility related facilities and services. I have defined a list of vocabularies for describing the facilities and services related to the accessibility issues. For example, the classification of main entrance door could be divided into the manual door, the powered door (push pad) and sensor door. Using AccessViaLift to describe whether there is a lift available to all floors? Using accessibleToilet to describe the availability of accessible toilet. There is still a lot of effort needed to complete the common vocabulary to describe the physical world accessibility. The benefit of using this common vocabulary could let the webmaster to describe the places accessibility without the need of specified knowledge fields. It also lets the search engine to index the accessibility information of physical places, which results to address the current information barriers for people with disabilities. If anything that I could do to help the development of this common vocabulary, please let me know. I am very glad to be involved in. Thank you again for your reply. >> >> Kind regards, >> Chaohai Ding >> >> PhD Student and Research Fellow >> Web and Internet Science Group (WAIS) >> School of Electronics and Computer Science >> University of Southampton >> mailto: cd8e10@ecs.soton.ac.uk >> >> ________________________________________ >> From: chaals@yandex-team.ru [chaals@yandex-team.ru] >> Sent: 19 September 2014 10:59 >> To: ding c. (cd8e10); public-vocabs@w3.org >> Subject: Re: Proposal: add properties for place accessibility >> >> Hello Chaohai, >> >> sorry to take such a long time to reply. >> >> 23.03.2014, 23:36, "ding c. (cd8e10)" <cd8e10@ecs.soton.ac.uk>: >>> Hi, >>> I am currently a PhD student focus on the research of using open data and linked data to enhance accessibility. During my currently research, I would not find any accessibility related properties for places in schema.org (as well as dbpedia ontologies). Although there is some accessibility properties for web content (accessibilityAPI, accessibilityControl, accessibilityFeature, accessibilityHazard), there is no metadata to describe the places accessibility, therefore, is it possible to propose a list of properties for place accessibility metadata. A simple example would be as follows: >>> property type expected value >>> isWheelchairAccessible text yes|limited|no|none >>> isMobilityImprAccessib text yes|limited|no|none >>> isVisualImpairmentAccessible text yes|limited|no|none >>> isHearImparimentAccessible text yes|limited|no|none >>> >>> or we could extend the current accessibility vocabularies for CreativeWork to places accessibility: >> I have created a testing branch with a *very* experimental approach, that takes a tiny subset of the information we really should have - whether a place is wheelchairFriendly. >> >> It has two propoerties: >> >> https://sdo-wip1.appspot.com/wheelchairFriendlyNotes whose range is text (including URI) - the idea is to describe *how* a place tries to be wheelchairFriendly >> >> https://sdo-wip1.appspot.com/isWheelchairUnfriendly is a boolean, where "True" means you'll probably have a hard time getting around this place with a wheelchair. >> >> They both apply to Place. >> >> My thinking is that we should encourage people who are describing how accessible their bar/restaurant/volcano/iceHockeyRink is to actually describe it, not just say "Of course I am", whereas the second one is more oriented in my mind at Review writers. >> >> And my overall goal is to get some experience of how ordinary webmasters use this in practice before we try to settle on a "serious" version. I'm concerned that when we add big chunks of things from specialised knowledge fields and ask non-specialists to use them that we get a mismatch, which makes the data less useful than we hope it will be. >> >> Anyway, I am interested in your comments and thoughts (as well as those of other people interested in this topic, of course). >> >> cheers >> >> Chaals >> >> -- >> Charles McCathie Nevile - web standards - CTO Office, Yandex >> chaals@yandex-team.ru - - - Find more at http://yandex.com -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 22 September 2014 10:52:43 UTC