Support linked data (e.g. for physical accessibility)

opyh commented 3 years ago

In the "Physical accessibility data in maps" workshop, we presented an idea to extend MapML with a way to semantically mark the physical accessibility of a displayed place.

This proposal would allow to add any semantics via Linked Data, for example via microformats, RDFa, or as JSON-LD snippet.

It would enable screenreaders and other accessibility assistants to make sense of MapML content, and add a whole new infrastructure for accessibility/navigation browser plugins, and could even create a new economic incentive to improve real-world accessibility.

You could use this to link:

Example browser features / extensions that this proposal would enable

Ranking places by accessibility (to incentivize businesses to improve their real, physical accessibility)
Support @speakable for voice assistants
Colorize place markers on all web maps using a traffic light system (green = accessible, red = not accessible) like on Wheelmap.org
Add context menu items to shown place markers to
- open an indoor map
- open the place or routing directions in another map application
- get a transit schedule for a station
Augment maps with accessibility features and hazards:
- accessible toilets
- elevators (with realtime operational status)
- (in)accessible sidewalks, ramps, and stairs
- environment noise levels

Example 1: RDFa lite

Here is one example how the syntax could look, using RDFa Lite:

<mapml vocab="https://schema.org" prefix="a11y: http://some-a11y-vocabulary.org/">
  <head>…</head>
  <body>
    <feature typeof="Hotel">
      <meta property="name" content="An awesome hotel 🏨">
        <meta property="amenityFeature" typeof="LocationFeatureSpecification">
          <meta property="name" content="Wheelchair-accessible Sauna" />
          <meta property="value" content="True" />
        </meta>
        <!--
          a standardized Linked Data vocabulary for accessibility does not exist yet, but a
          standardization of physical a11y is going to be part of schema.org soon.
          [A11yJSON](https://a11yjson.org) is an example how such a schema could look like.
        -->
        <meta property="a11y:animalPolicy" typeof="a11y:AnimalPolicy">
          <meta property="a11y:allowsGuideDogs" content="True" />
        </meta>
      </meta>
      <geometry>…</geometry>
      <properties>…</properties>
    </feature>
  </body>
</mapml>

RDFa lite would add the following attributes: vocab, typeof, property, resource, and prefix. It would make use of the existing meta element.

Using schema.org's sameAs property, this would also allow linking external APIs to let a user agent request semantic data with extra HTTP requests.

Example 2: JSON-LD / `script`

An alternative could be to allow JSON-LD script elements (example copied from https://schema.org/Hotel):

  <script type="application/ld+json">
  {
      "@context": "https://schema.org",
      "@type": "Hotel",
      "name": "ACME Hotel Innsbruck",
      "description": "A beautifully located business hotel right in the heart of the alps. Watch the sun rise over the scenic Inn valley while enjoying your morning coffee.",
      "address": {
          "@type": "PostalAddress",
          "addressCountry": "AT",
          "addressLocality": "Innsbruck",
          "addressRegion": "Tyrol",
          "postalCode": "6020",
          "streetAddress": "Technikerstrasse 21"
      },
      "telephone": "+43 512 8000-0",
      "photo": "http://www.acme-innsbruck.at//media/hotel_front.png",
      "starRating": {
          "@type": "Rating",
          "ratingValue": "4"
      },
      "priceRange": "$100 - $240",
      "cssSelector": ["feature:nth-child(10)"]
  }</script>

Would keep the map structure and semantics more separate
Allows to include a JSON-LD definition from an external URL using a src attribute
You could backreference MapML elements with a semantic property, like @speakable, via a CSS or XPath selector

`<link href="">`

If you have a sensible idea how to use the existing <link href=""> element for linking a data set, please leave your idea here :)

frastlin commented 3 years ago

I wonder if we can minimize the amount of A11Y specific information and have a list of general properties each feature should contain. Information such as accessible sidewalks, and ramps, for example, would be useful for more than just those with wheelchairs. Anyone who is lugging a giant suitcase from the airport to their hotel can attest to this. We should have another topic listing out the features that should be listed in the data, as if we leave this up to map creators, they won't know what kind of accessibility information is important. For example, technically every location should allow dog guides, so that's not really important, but knowing where dog guides can be taken to go potty, and where the trash can is, may be much more useful.

prushforth commented 3 years ago

Thanks for these comments. As a way of protecting the future project from problems due to intellectual property considerations, please consider joining the W3C Maps for HTML Community Group, which requires certain IP grants from you to the community for the purpose of standardizing ideas like these. We'll then send you a GitHub invitation to join other contributors here. You and your contributions are most welcome!

That said, I believe that the markup skeleton that you are setting up with <meta> elements has an intended home in the properties element, and potentially even the <geometry> element. So, you could have a <div> in there, marked up with RDF-a attributes as appropriate. Or anything else that's 'legal' in HTML, we think:

<feature>
     <properties>... any 'regular' HTML goes here... </properties>
       <geometry> ... would it be useful to semantically mark up geometry elements (including embedded <a href>...</a>?... </geometry
</feature>

So, your example might look like but would not be restricted to the following markup:

<feature vocab="https://schema.org" typeof="Hotel">
     <properties>
        <span property="name">An awesome hotel 🏨</span>
        <div property="amenityFeature" typeof="LocationFeatureSpecification">
          <span property="name">Wheelchair-accessible Sauna</span>
          <span property="value">True</span>
        </div>
        <!--
          a standardized Linked Data vocabulary for accessibility does not exist yet, but a
          standardization of physical a11y is going to be part of schema.org soon.
          [A11yJSON](https://a11yjson.org) is an example how such a schema could look like.

         So we're just brainstorming here, but again instead of non-standard meta elements, just use HTML FTW:
        -->
        <div typeof="a11y:AnimalPolicy">
           <span property="a11y:allowsGuideDogs">True</span>
        </div>

     </properties>
       <geometry> ... would it be useful to semantically mark up geometry elements (including embedded <a href>...</a>?... </geometry
</feature>

Re: script, we have so far shied away from specifying that <script> would be legal in MapML documents, because of the security implications.

opyh commented 3 years ago

Thanks for your feedback! I’ve joined the Maps4HTML CG + GItHub org.

Re which accessibility attributes to include: the proposal aims to enable authors to link data in any vocabulary, no matter how complex or lightweight - also vocabularies that have nothing to do with accessibility. Likely, there will soon be different vocabularies for accessibility with varying levels of detail. https://github.com/schemaorg/schemaorg/issues/254 is a GitHub issue showing such a discussion for schema.org. The example above was using a fictional vocabulary (http://some-a11y-vocabulary.org/).

Re where to put the elements: True, for my example case, it makes more sense to put the tags into the properties. Other examples where adding semantics can make sense:

Authors might want to describe the semantics for a whole set of features, a layer, or even the whole map. They could link a document’s authors, an organization, or a scientific paper.
geometry could be a 2D map representation linked to a whole 3D/4D model in any other format as long as there is a vocabulary for it, or have a link between a polygon and a building part.

As this list is not exhaustive, I think if we choose RDFa as the first supported syntax for Linked Data, the format should allow the new RDFa properties on all elements, as it does in HTML.

Re <meta>: <meta> elements would be a way to include semantic information without other (visible) element representations in the document structure. If properties contains visual elements that represent the semantic data, that’s better, of course :)

Re <script>: True, as soon as this would support external sources via the src attribute, this could be an obstacle to get started.

So… Should we include RDFa directly in the standard? If so, which version? https://www.w3.org/TR/rdfa-lite/?

prushforth commented 3 years ago

So… Should we include RDFa directly in the standard? If so, which version? https://www.w3.org/TR/rdfa-lite/?

I strongly endorse the minimum viable complexity that will work for your use cases approach, so rdfa-lite looks reasonable. A key first step will be describing a map-based use case or category of use cases that shows us the way for how the rdfa markup could be used by the UA. Then I guess we'll need to extend the schema to include the attributes, so that they can potentially be "validated". I don't know how much RDF-A the W3C validator supports, but I suppose we could use that to see what we might be aiming at. I think the idea of the validator was originally to use schematron to validate constraints, but I believe that has ended up with implementing custom constraint validation in java.

It's not all about validation, we need to probably implement/prototype some behaviour? @kmcglinn is interested in linked building data. Maybe we should set up a call in the near future to explore pathways forward?

opyh commented 3 years ago

As visible above, I've added a use case idea that's hopefully simple enough to get started.

Malvoz commented 3 years ago

Just an observation: The HTML <track> media element supports the kind="metadata" attribute, where the src can point to a resource with track cues in JSON format 👀

If kind was supported by the <layer> element (would need to be discussed separately), you could potentially hook up accessibility metadata like so:

<map ...>
  <layer src="map-markup.mapml"></layer>
  <layer src="a11y.json" kind="metadata"></layer>
</map>

map-markup.mapml:

...
<geometry>
  <point>
    <coordinates>2.376757 48.898991</coordinates>
  </point>
</geometry>

a11y.json:

{
  "geometry": { "type": "Point", "coordinates": [2.376757, 48.898991] },
  "properties": {
    "category": "cinema",
    "name": "Ciné XY",
    "accessibility": {
      "entrances": [
        { "name": "30th St", "isMainEntrance": true, "isLevel": false },
        { "name": "Side gate", "hasFixedRamp": true }
      ],
      "accessibleWith": {
        "wheelchair": true
      },
      "animalPolicy": {
        "allowsGuideDogs": true
      }
    }
  }
}

This obviously separates the metadata from the map markup (not saying that the map markup couldn't provide metadata inline in addition), which I suppose could have both pros and cons.

opyh commented 3 years ago

@Malvoz Good idea. I think in the end we should have both, RDFa and external JSON-LD (which I'd prefer over using A11yJSON directly, as A11yJSON is no Linked Data standard). For a user agent to make sense of this, there would have to be references to the single map elements for this to work. schema.org does something similar with the speakable specification: It allows to provide references to document elements via their CSS selectors, so you can have an association between a visual element and its semantics.

Maps4HTML / MapML-Specification