sozialhelden / a11yjson Goto Github PK

I would like to add the following properties to Entrance:

Left and right from the perspective in front of the building/place.

I had a hard time finding information about elevator modelling in your specification. This is the only information i could find:

https://github.com/sozialhelden/ac-format/search?q=elevator&unscoped_q=elevator

I guess there is no more information about it yet?

I would propose an entity Elevator which has the following properties:

Feel free to adapt the properties, if there is a more suitable word in English.

Status: clarified

for example: "properties-accessibility-payment-customPaymentWithNFC"
Contactless payment refers to a payment function in which payments e.g. B. be handled via Near Field Communication (NFC). Contactless payment is used today by most payment cards and current smartphones.

What is required to rate something isAccessibleWithWheelchair = true? Are there any objective measures that must be given to rate something accessible with wheelchairs?

I would like to add these new properties to Stairs:

• firstAndLastStepColorized (boolean) - Existing properties like hasHighContrastNosing don't seem to fit here.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Hi, I want to use model but first I have to import interface to my database. How I can do that easily? A json format aside with table one would be great.

I would like to add the following properties to PlaceInfo:

I would like to know how you identify a place in a unique way? For instance, by a given ID string.

If i understand a11y right, there is the ids property for PlaceProperties, which contains ExternalId references. But its not meant to be used to identify a place, like a certain supermarket located under a given address, am i right? Its current use is not clear to me.

In the RDF/Linked Open Data space we use an URI / IRI to identify resources on a global scale. A simple example: http://my_website/supermarketXY

Would be open to extend PlaceInfo (or PlaceProperties) by an identifier property, which contains an URI or IRI?

I would like to be compatible to your specification with my own data, but there are differences in modelling, which have to be bridged. So before going into detail, is there a process to propose / discuss changes/additions to the specification?

Thanks.

In this proposal i'd like to discuss properties of Toilet and usage of FoldingHandles.

Toilet

The Toilet entity has the following properties currently:

• spaceInFront
• spaceOnUsersRightSide
• spaceOnUsersLeftSide
• foldingHandles
• hasFoldingHandles
• heightOfBase

(1)

Could you please tell me, what "space" means, for instance in spaceOnUsersLeftSide? Do you mean the length or the depth of the area left/right of the user?

(2)

Using foldingHandles is a little bit narrow, because there are support handles which are not foldable. Would you be open to add more details here?

I would like to propose the following property additions to the Toilet entity.

The following properties clarify:

• available space in the toilet
• emergency bell information
• door information
• steps and handrail information till toilet

FoldingHandle => SupportHandle

I would like to rename it to SupportHandle, because there are handles, which are not foldable. If you enforce FoldingHandle, other types of handles have to be created with the same/similar properties.

I would change it to:

Feel free to adapt the properties, if there is a more suitable word in English.

EDIT: I cancelled Door and Stairs related properties in favor of using Door and Stairs instances directly.

EDIT 2: Relation to FoldableHandles discussed; proposal to renaming it to SupportHandle.

This would allow EquipmentInfo and -Properties to be used for emergency bell modelling.

Why are properties of a Place attached to PlaceProperties instead of PlaceInfo? Same goes for EquipmentInfo and EquipmentProperties.

But why not for Entrance? All properties are directly attached to it, no "proxy" entity.

We have data sets describing existing media without referring to a title, but there is a plaintext description which media exists and how to access it.

What do you think about extending the specification with information about car rental stations? Which properties might be of interest?

Motivation

One might want to know if the station is reachable or if there are notable obstacles, like holes or threshold on the way. For me its not about rental stations with cars for people with disabilities. Its about people who might want to know, for instance, if their grandparents with rollator can reach the station resp. cars.

Random thoughts

• Main entity should be Parking.
• Because stations are mostly with cars not suitable for wheelchair users, WheelchairParking could be ignored here IMHO.
• When starts the station? So here pathways around the station of interest? What radius makes sense?
• The following questions should be answered:
  1. Has the station a door i have to use? (e.g. door width, door height, automatic or not,..)
  2. Has the area obstacles, like holes in the ground, which might hinder you?
  3. How accessible are the ways to the station, like from the next main street or TRAM station?

What do you think?

@opyh: As we discussed; here is some input from my side.

During my research i found the following vocabularies and schemata, which may be of interest for a11y-json.

Linked Open Data / RDF

• The vocabulary for (L)OD description of wheelchair accessibility - http://semweb.mmlab.be/ns/wa#
• Basic Geo (WGS84 lat/long) Vocabulary - http://www.w3.org/2003/01/geo/ (you may already know that)
• dbpedia - https://dbpedia.org (and the wiki) (DBpedia is basically the RDF version of the wikipedia and therefore more meaningful information. It might be worth it to check their properties/classes.)
• DCMI Metadata Terms and - Elements - http://dublincore.org/specifications/dublin-core/dcmi-terms/2012-06-14/ (Dublin Core metadata terms cover a wide area of basic terms, including language, license, locations and physical resources. Its heavily used.)

Side note: In the Linked Open Data / Semantic Web community it is common that you try to reuse existing schemata / ontologies / vocabularies. In practice its hard to follow it all the time, because sometimes existing models/properties/classes don't fit your current use case 100%. We should take a deeper look in this space to spot further sources. Chances are high that other repositories may also using this, which automatically increases compatibility.

Common data specifications/vocabularies

• Schema.org - http://schema.org/ (i guess its widely known, but i have not seen any properties in this specification. for instance PostalAddress or OpeningHoursSpecification may candidates for future work.)
  • Regarding opening hours: Google provides a detailed site, about which data/properties are relevant: https://developers.google.com/search/docs/data-types/local-business

About the dbpedia

Its an important data source and -reference in the Linked Open Data / RDF community. If an use case is about something in the Wikipedia, related DBpedia resources will be used. That is a common way to find consensus and similarities in data and concepts. I can help here. A big advantage: If a11y-json resources reference DBpedia entries and are transformed to RDF, related data can be merged very easily.

Further information:

• Overviews here and here
• Paper about DBpedia with more details, technical information and its history

I would like to add the following properties to EquipmentProperties in order to support more information about ramps.

I've chose the ramp suffix to be in line with properties like cabinLength and cabinWidth.

Using hasHandRail is not enough, because sometimes you only have a handrail on one side. For my case i would prefer information if there is one on each side, or not.

EDIT: Adapted the Type for ramp* properties.

I would like to add the following properties to Door:

Side notes:

• unlockableFromTheOutside - That information is important for toilet doors. For safety reasons some doors are unlockable from the outside.

Both formats have interesting attributes that A11yJSON should be more compatible with:

https://github.com/NeTEx-CEN/NeTEx/blob/17c3b065ed5772e751dcdc6477360629604d2a0a/xsd/netex_part_1/part1_ifopt/netex_ifopt_equipmentAccess_version.xsd#L455

https://developers.google.com/transit/gtfs/reference/#pathwaystxt

I would like to add the following properties to Parking:

Notices:

• count - Information about the number of parking slots is also relevant, for instance, may i park in front of the building/on site or do i have to search somewhere around the place?

There can be equipment, which has more than 1 door, for instance elevators. EquipmentProperties.door should therefore be renamed to doors.

The same goes for Entrance, there are places which have multiple doors in the entrance area.

This change would be in line with Entrance.stairs.

This is helpful for a lot of accessibility relevant use cases.