New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal of accessMode, accessModeSufficient, and accessibilitySummary properties for e.g. epubs #1100

Open
madeleinerothberg opened this Issue Apr 13, 2016 · 91 comments

Comments

Projects
None yet
@madeleinerothberg

This proposal comes from the digital publishing community, and specifically from the Epub 3.1 Accessibility Working Group (with support from the whole Epub 3.1 group).

This proposal addresses use cases in digital publishing for accessible ebooks for which current metadata is not sufficient. These use cases require distinguishing between an ebook which has the complete text and audio of the work, one with the complete text and partial audio, and one with the complete audio and partial text. Additional permutations of this sort arise as multimedia in ebooks is factored in, requiring an access mode-based solution rather than a vocabulary of types of books.

Like the existing accessibility properties, these new properties can apply to any CreativeWork. They might apply to physical books in some cases (particularly braille books and audio books on physical media) but this work is probably separate from the bibliographic extension.

We are proposing three properties:
accessMode: The human sensory perceptual system or cognitive faculty through which a person may process or perceive information.

accessModeSufficient: A list of single or combined accessModes that are sufficient to understand all the intellectual content of a resource.

accessibilitySummary: A human-readable summary of specific accessibility features or deficiencies, consistent with the other accessibility metadata but expressing subtleties such as "short descriptions are present but long descriptions will be needed for non-visual users" or "short descriptions are present and no long descriptions are needed."

accessMode is important for defining the basic contents of a file. Is this an ebook with audio or plain text? Are there visuals? Having this information allows a more personalized search process because tools can support users who are looking for materials that meet their needs with or without accessibilityFeatures.

accessModeSufficient is important for distinguishing the various ebook types described above. The use cases in our proposal show in detail why this is necessary to permit fine-grained description of accessible ebooks. It permits a metadata author to be specific about what combinations of access modes will give full access to a resource. Some metadata authors may not wish to author this property; they will still be able to make use of accessMode, which is simpler. Publishers working intensively on accessible ebooks will be motivated to understand and use both properties.

accessModeSufficient may also be useful to search engines seeking to filter resources for users. In some cases, it serves as an encoding of the combination of accessModes and accessibilityFeatures, revealing, for example, that a silent video is accessible even though it lacks captions, because there is no audio to be captioned, or that a web page that has images is accessible to a non-visual user because the images have been described.

accessibilitySummary offers a backup for subtle information that is hard to communicate with structured metadata but might be important to readers searching for a suitable ebook or other resource.

These properties are suitable for non-ebook use as well. Any multimedia resource can be better described with these properties.

The proposal is detailed at the following page, including use cases:
https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

danbri added a commit that referenced this issue Apr 13, 2016

danbri added a commit that referenced this issue Apr 13, 2016

danbri added a commit that referenced this issue Apr 13, 2016

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 13, 2016

Contributor

Thanks for the detailed proposal. I have made a pass at implementing it for wider review and discussion.

Draft available at:

In putting this together the most obvious question to ask was about the values of these properties. Schema.org has the notion of an Enumeration, which allows us to define natural-language-neutral URLs for well known property values (e.g. http://schema.org/True). Our previous accessibility-related properties e.g. http://schema.org/accessibilityFeature haven't yet used this construct and instead documented rough lists of possible values in a Wiki. I have for now followed that approach here, and have made a JSON-LD example which shows repeated use of a property for multiple values. This will look somewhat more verbose in RDFa/Microdata. Was this approach your intention or should we look to define more rigid enumerations for accessMode and accessibilitySummary? /cc @betehess who has been investigating the tradeoffs around strings vs enumerated URLs for opening hours ("Monday" vs http://schema.org/Monday etc.).

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"],
  "accessibilitySummary": "Visual elements are not described."
}
</script>

Also: accessibilitySummary ... can we think through whether this broadly-named property could also serve a purpose for real world / physical accessibility eg. of places? We have discussed such functionality previously (#254).

/cc @chaals @vholland @rvguha @pmika @scor @shankarnat @tmarshbing

Contributor

danbri commented Apr 13, 2016

Thanks for the detailed proposal. I have made a pass at implementing it for wider review and discussion.

Draft available at:

In putting this together the most obvious question to ask was about the values of these properties. Schema.org has the notion of an Enumeration, which allows us to define natural-language-neutral URLs for well known property values (e.g. http://schema.org/True). Our previous accessibility-related properties e.g. http://schema.org/accessibilityFeature haven't yet used this construct and instead documented rough lists of possible values in a Wiki. I have for now followed that approach here, and have made a JSON-LD example which shows repeated use of a property for multiple values. This will look somewhat more verbose in RDFa/Microdata. Was this approach your intention or should we look to define more rigid enumerations for accessMode and accessibilitySummary? /cc @betehess who has been investigating the tradeoffs around strings vs enumerated URLs for opening hours ("Monday" vs http://schema.org/Monday etc.).

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"],
  "accessibilitySummary": "Visual elements are not described."
}
</script>

Also: accessibilitySummary ... can we think through whether this broadly-named property could also serve a purpose for real world / physical accessibility eg. of places? We have discussed such functionality previously (#254).

/cc @chaals @vholland @rvguha @pmika @scor @shankarnat @tmarshbing

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 13, 2016

Contributor

So interpreting what the array means is where I got stuck. In your example, you need all the modes. But many resources have multiple sets of accessModeSufficient. So given a movie which requires either audio, or visual+text, to be usable, does something like the following work?

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"]
  "accessModeSufficient": ["audio"],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}
</script>

Also: accessibilitySummary ... can we think through whether this broadly-named property could also serve a purpose for real world / physical accessibility eg. of places? We have discussed such functionality previously (#254).

Yes, it wouldn't be a bad start.

Contributor

chaals commented Apr 13, 2016

So interpreting what the array means is where I got stuck. In your example, you need all the modes. But many resources have multiple sets of accessModeSufficient. So given a movie which requires either audio, or visual+text, to be usable, does something like the following work?

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"]
  "accessModeSufficient": ["audio"],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}
</script>

Also: accessibilitySummary ... can we think through whether this broadly-named property could also serve a purpose for real world / physical accessibility eg. of places? We have discussed such functionality previously (#254).

Yes, it wouldn't be a bad start.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Apr 13, 2016

Charles,
You are interpreting the array of accessModeSufficient values correctly. The intent is that user must be able to use all of the modes in any one line together to fully use the resource, but in some cases there are several distinct combinations that are sufficient, each with their own accessModeSufficient statement. Your movie example works perfectly. It would make sense to add

"accessibilityFeature": ["audioDescription", "captions"]

Use of accessibilitySummary for general description of accessible places makes sense. We would need to edit the definition, and I would suggest adding a warning that if structured metadata fields are available, they should be used instead of or in addition to a plain-text summary. If summary is the only field adopted widely, we will have less functionality than if accessMode and accessibilityFeature are adopted widely.

Charles,
You are interpreting the array of accessModeSufficient values correctly. The intent is that user must be able to use all of the modes in any one line together to fully use the resource, but in some cases there are several distinct combinations that are sufficient, each with their own accessModeSufficient statement. Your movie example works perfectly. It would make sense to add

"accessibilityFeature": ["audioDescription", "captions"]

Use of accessibilitySummary for general description of accessible places makes sense. We would need to edit the definition, and I would suggest adding a warning that if structured metadata fields are available, they should be used instead of or in addition to a plain-text summary. If summary is the only field adopted widely, we will have less functionality than if accessMode and accessibilityFeature are adopted widely.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 13, 2016

Contributor

@madeleinerothberg yes it makes sense to add the accessibilityFeatures.

@danbri does my syntax give the right structure? I've got a head full of 'flu, but it strikes me that there should be a node in the middle, so the resulting data doesn't look like

resource -> accessModeSufficient -> (the two arrays, merged).

?

Contributor

chaals commented Apr 13, 2016

@madeleinerothberg yes it makes sense to add the accessibilityFeatures.

@danbri does my syntax give the right structure? I've got a head full of 'flu, but it strikes me that there should be a node in the middle, so the resulting data doesn't look like

resource -> accessModeSufficient -> (the two arrays, merged).

?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 14, 2016

Contributor

Ah, yes it sounds like some substructure is needed then.

Also I think related to @chaals' point: there's a convention that we try to stick to which is that the meaning of one property/value pair ought not to be undermined by a nearby additional property/value pair, to avoid confusion if the data is subsetted. I don't think we always stick to it though. Sorry that isn't the most helpful explanation, I'll try to work through an example asap.

Contributor

danbri commented Apr 14, 2016

Ah, yes it sounds like some substructure is needed then.

Also I think related to @chaals' point: there's a convention that we try to stick to which is that the meaning of one property/value pair ought not to be undermined by a nearby additional property/value pair, to avoid confusion if the data is subsetted. I don't think we always stick to it though. Sorry that isn't the most helpful explanation, I'll try to work through an example asap.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Apr 20, 2016

Yes, we need some way for each accessModeSufficient statement to remain separate. I wouldn't say that one statement "undermines" the next; each one adds more data about the resource being described without changing the truthfulness of the previous statements. But that might be different than your intended meaning for undermined.

Yes, we need some way for each accessModeSufficient statement to remain separate. I wouldn't say that one statement "undermines" the next; each one adds more data about the resource being described without changing the truthfulness of the previous statements. But that might be different than your intended meaning for undermined.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 28, 2016

Contributor

I think we should move forward on accessibilitySummary while we figure out how to get the model right for the other two. It would indeed be a very valuable property to describe places and products.

Contributor

chaals commented Apr 28, 2016

I think we should move forward on accessibilitySummary while we figure out how to get the model right for the other two. It would indeed be a very valuable property to describe places and products.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 29, 2016

Contributor

@madeleinerothberg - yes, I was trying to say that we want an additive design as you outline

Contributor

danbri commented Apr 29, 2016

@madeleinerothberg - yes, I was trying to say that we want an additive design as you outline

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Apr 29, 2016

I'd be happy to move forward with accessibilitySummary and accessMode (which does not require complicated modeling), but let's not delay figuring out the model for accessModeSufficient. Having summary without the others would encourage use of less structured data when more structure is ultimately going to provide better results. The EPUB community is also eager to get this metadata in place and is moving toward a version 3.1. How can we work this out? Would a synchronous call for interested participants be helpful?

I'd be happy to move forward with accessibilitySummary and accessMode (which does not require complicated modeling), but let's not delay figuring out the model for accessModeSufficient. Having summary without the others would encourage use of less structured data when more structure is ultimately going to provide better results. The EPUB community is also eager to get this metadata in place and is moving toward a version 3.1. How can we work this out? Would a synchronous call for interested participants be helpful?

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg May 25, 2016

With Schema 3.0 launched, I'd like to see these accessibility proposals included in the next release. What is necessary to do that?

With Schema 3.0 launched, I'd like to see these accessibility proposals included in the next release. What is necessary to do that?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 1, 2016

Contributor

Per email exchange, let's try to have a call with @chaals and any other interested parties in early-mid June.

Contributor

danbri commented Jun 1, 2016

Per email exchange, let's try to have a call with @chaals and any other interested parties in early-mid June.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 30, 2016

Contributor
{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"],
  "accessModeSufficient": ["audio"],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

parses to

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient "audio" .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .

Contributor

danbri commented Jun 30, 2016

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": ["textual", "visual"],
  "accessModeSufficient": ["audio"],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

parses to

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient "audio" .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 30, 2016

Contributor

rough example attempt

{
"@context": "http://schema.org/",
"@type": "Movie",
"name": "Some graphic novel",
"accessMode": ["textual", "visual"],
"accessModeSufficient": { "@list": ["textual", "visual"] },
"accessModeSufficient": { "@list": ["audio"] },
"accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

but I don't see what I expect in http://json-ld.org/playground/ per https://www.w3.org/TR/json-ld/#sets-and-lists

Contributor

danbri commented Jun 30, 2016

rough example attempt

{
"@context": "http://schema.org/",
"@type": "Movie",
"name": "Some graphic novel",
"accessMode": ["textual", "visual"],
"accessModeSufficient": { "@list": ["textual", "visual"] },
"accessModeSufficient": { "@list": ["audio"] },
"accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

but I don't see what I expect in http://json-ld.org/playground/ per https://www.w3.org/TR/json-ld/#sets-and-lists

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 30, 2016

Contributor

AHA

this.

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ { "@list": ["textual", "visual"] }, { "@list": ["audio"] } ],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient _:b1 .
_:b0 http://schema.org/accessModeSufficient _:b3 .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .
_:b1 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "textual" .
_:b1 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest _:b2 .
_:b2 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "visual" .
_:b2 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest http://www.w3.org/1999/02/22-rdf-syntax-ns#nil .
_:b3 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "audio" .
_:b3 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest http://www.w3.org/1999/02/22-rdf-syntax-ns#nil .

Alternative would be to use http://schema.org/ItemList

Contributor

danbri commented Jun 30, 2016

AHA

this.

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ { "@list": ["textual", "visual"] }, { "@list": ["audio"] } ],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient _:b1 .
_:b0 http://schema.org/accessModeSufficient _:b3 .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .
_:b1 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "textual" .
_:b1 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest _:b2 .
_:b2 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "visual" .
_:b2 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest http://www.w3.org/1999/02/22-rdf-syntax-ns#nil .
_:b3 http://www.w3.org/1999/02/22-rdf-syntax-ns#first "audio" .
_:b3 http://www.w3.org/1999/02/22-rdf-syntax-ns#rest http://www.w3.org/1999/02/22-rdf-syntax-ns#nil .

Alternative would be to use http://schema.org/ItemList

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 30, 2016

Contributor

Here is an alternative formulation that does not use RDF (ie. JSON-LD + RDFa friendly) lists, but instead uses the ListItem construction we have within schema.org:

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ 
       { "@typeof": "ListItem", "itemListElement": ["textual", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["audio"] } ],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

The triples view from JSON-LD parser (the Playground tool again) is:

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient _:b1 .
_:b0 http://schema.org/accessModeSufficient _:b2 .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .
_:b1 http://schema.org/@typeof "ListItem" .
_:b1 http://schema.org/itemListElement "textual" .
_:b1 http://schema.org/itemListElement "visual" .
_:b2 http://schema.org/@typeof "ListItem" .
_:b2 http://schema.org/itemListElement "audio" .

Tradeoff is that this design is syntax-neutral and works equally well or badly in Microdata. In doing so it opts out of the syntax-level support in JSON-LD (via "@list") and in RDFa 1.1 (via @inlist ).

https://www.w3.org/TR/rdfa-syntax/#list-generation

Contributor

danbri commented Jun 30, 2016

Here is an alternative formulation that does not use RDF (ie. JSON-LD + RDFa friendly) lists, but instead uses the ListItem construction we have within schema.org:

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ 
       { "@typeof": "ListItem", "itemListElement": ["textual", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["audio"] } ],
  "accessibilitySummary": "There is audio description, and closed captioning of the main audio"
}

The triples view from JSON-LD parser (the Playground tool again) is:

_:b0 http://schema.org/accessMode "textual" .
_:b0 http://schema.org/accessMode "visual" .
_:b0 http://schema.org/accessModeSufficient _:b1 .
_:b0 http://schema.org/accessModeSufficient _:b2 .
_:b0 http://schema.org/accessibilitySummary "There is audio description, and closed captioning of the main audio" .
_:b0 http://schema.org/name "Some graphic novel" .
_:b0 http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Movie .
_:b1 http://schema.org/@typeof "ListItem" .
_:b1 http://schema.org/itemListElement "textual" .
_:b1 http://schema.org/itemListElement "visual" .
_:b2 http://schema.org/@typeof "ListItem" .
_:b2 http://schema.org/itemListElement "audio" .

Tradeoff is that this design is syntax-neutral and works equally well or badly in Microdata. In doing so it opts out of the syntax-level support in JSON-LD (via "@list") and in RDFa 1.1 (via @inlist ).

https://www.w3.org/TR/rdfa-syntax/#list-generation

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 30, 2016

Contributor

Q: to what extent could these concepts be applied to description of Events?

Contributor

danbri commented Jun 30, 2016

Q: to what extent could these concepts be applied to description of Events?

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jun 30, 2016

Contributor

FWIW I don't think that modelling things as untyped lists of lists is very human-friendly, or in fact good modelling. Doubly so as none of the lists in question are in fact ordered, which means they aren't really lists... Semantically, this is saying that ["textual", "visual"] is a different requirement from ["visual", "textual"] — I don't think that's true.

At this point we're really better off having a new class, says AccessModality. This has the added advantage that you can also attach a useful description to it, an indication of how to access a given modality. The modalities on one AccessModality are anded; several AccessModalitys can be specified and those are ored.

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ 
    {
      "@type": "AccessModality",
      "requiredModality": ["textual", "visual"],
      "name": "Closed-captioning"
    },
    {
      "@type": "AccessModality",
      "requiredModality": ["audio"],
      "description": "Audio description",
      "url": "http://berjon.com/singing-some-beyonce.mp3"
    }
  ]
}

This might further obviate the need for accessibilitySummary since the modalities can describe that. It could also be more oriented towards universal design (rather than just a11y) and be used to specify other aspects (eg. requires a touch device, a colour screen…)

Contributor

darobin commented Jun 30, 2016

FWIW I don't think that modelling things as untyped lists of lists is very human-friendly, or in fact good modelling. Doubly so as none of the lists in question are in fact ordered, which means they aren't really lists... Semantically, this is saying that ["textual", "visual"] is a different requirement from ["visual", "textual"] — I don't think that's true.

At this point we're really better off having a new class, says AccessModality. This has the added advantage that you can also attach a useful description to it, an indication of how to access a given modality. The modalities on one AccessModality are anded; several AccessModalitys can be specified and those are ored.

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "name": "Some graphic novel",
  "accessMode": ["textual", "visual"],
  "accessModeSufficient": [ 
    {
      "@type": "AccessModality",
      "requiredModality": ["textual", "visual"],
      "name": "Closed-captioning"
    },
    {
      "@type": "AccessModality",
      "requiredModality": ["audio"],
      "description": "Audio description",
      "url": "http://berjon.com/singing-some-beyonce.mp3"
    }
  ]
}

This might further obviate the need for accessibilitySummary since the modalities can describe that. It could also be more oriented towards universal design (rather than just a11y) and be used to specify other aspects (eg. requires a touch device, a colour screen…)

@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Jun 30, 2016

Your approach sounds interesting, will be interested to hear what others think. This approach would not replace the need for accessibilitySummary as this can be used outside of accessModeSufficient for other accessibility descriptions needed in other disciplines other than Digital Publishing.

Your approach sounds interesting, will be interested to hear what others think. This approach would not replace the need for accessibilitySummary as this can be used outside of accessModeSufficient for other accessibility descriptions needed in other disciplines other than Digital Publishing.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 30, 2016

Contributor

@darobin. - the motivation for a list is that it becomes harder to accidentally subset the data, casually altering its semantics quite strongly. The encoding of OWL rules in RDF/S exploited similar structures. It ain't pretty, for sure, but when what you want to say doesn't really partition into independent triples the options are awkward.

Contributor

danbri commented Jun 30, 2016

@darobin. - the motivation for a list is that it becomes harder to accidentally subset the data, casually altering its semantics quite strongly. The encoding of OWL rules in RDF/S exploited similar structures. It ain't pretty, for sure, but when what you want to say doesn't really partition into independent triples the options are awkward.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Jun 30, 2016

Writing existing use cases in the syntax DanBri proposed, we get these examples. Comments and corrections welcome.

Use case 2.B from:
https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

"Alice in Wonderland" – Children's book with illustrations
A novel for children, with complementary illustrations.
Case 2.B - audio media overlays for the text of the story, short descriptions of illustrations.

According to syntax in:
#1100 (comment)

{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ { "@list": ["textual"] }, { "@list": ["textual", "visual"] }, { "@list": [“auditory"] }, { "@list": ["auditory", "visual"] }, { "@list": ["auditory", "visual"] }, { "@list": ["auditory", "visual", "textual"] } ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

If instead we use the syntax in:
#1100 (comment)

{
  "@context": "http://schema.org/",
  "@type": “Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ 
       { "@typeof": "ListItem", "itemListElement": ["textual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["textual", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "textual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "textual", "visual"] } ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

madeleinerothberg commented Jun 30, 2016

Writing existing use cases in the syntax DanBri proposed, we get these examples. Comments and corrections welcome.

Use case 2.B from:
https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

"Alice in Wonderland" – Children's book with illustrations
A novel for children, with complementary illustrations.
Case 2.B - audio media overlays for the text of the story, short descriptions of illustrations.

According to syntax in:
#1100 (comment)

{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ { "@list": ["textual"] }, { "@list": ["textual", "visual"] }, { "@list": [“auditory"] }, { "@list": ["auditory", "visual"] }, { "@list": ["auditory", "visual"] }, { "@list": ["auditory", "visual", "textual"] } ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

If instead we use the syntax in:
#1100 (comment)

{
  "@context": "http://schema.org/",
  "@type": “Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ 
       { "@typeof": "ListItem", "itemListElement": ["textual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["textual", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "visual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "textual"] }, 
       { "@typeof": "ListItem", "itemListElement": ["auditory", "textual", "visual"] } ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}
@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jun 30, 2016

Contributor

@danbri That can support the case for @list (though I would contend it is a case for @set) in the branches, but not a case for lists of lists.

Also I'm not sure about the "accidentally subset data" problem; I mean this could happen at any time, and is very dependent on how you process the data. We can't be defensive against all such arbitrary cases, unless we start hashing, no?

Contributor

darobin commented Jun 30, 2016

@danbri That can support the case for @list (though I would contend it is a case for @set) in the branches, but not a case for lists of lists.

Also I'm not sure about the "accidentally subset data" problem; I mean this could happen at any time, and is very dependent on how you process the data. We can't be defensive against all such arbitrary cases, unless we start hashing, no?

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Jul 6, 2016

@chaals, @danbri, does @set make sense? @darobin is correct that the items in the groups (and the groups themselves) do not require a specific order. What is the best way to model this aspect?

@chaals, @danbri, does @set make sense? @darobin is correct that the items in the groups (and the groups themselves) do not require a specific order. What is the best way to model this aspect?

@jaygray0919

This comment has been minimized.

Show comment
Hide comment
@jaygray0919

jaygray0919 Jul 6, 2016

@set is a W3C JSON-LD issue: https://www.w3.org/TR/json-ld/
Is there order in set? I was not aware of that.

@set is a W3C JSON-LD issue: https://www.w3.org/TR/json-ld/
Is there order in set? I was not aware of that.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Jul 6, 2016

@jaygray0919, Robin implied that @set does not imply order, while @list does. That matches what I understand in the JSON-LD spec. For accessModeSufficient, order is not important, but correctly interpreting the array is critical.

@jaygray0919, Robin implied that @set does not imply order, while @list does. That matches what I understand in the JSON-LD spec. For accessModeSufficient, order is not important, but correctly interpreting the array is critical.

@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Jul 8, 2016

Just as a side remark: it is indeed correct that RDF/OWL does use RDF Lists when, in fact, unordered collections are required model wise (see, e.g., the Class Disjointness Example in the OWL Primer). This could be considered a hack; I am not sure it is a good idea to make this hack explicit, because it just leads to misunderstandings. In other words, I think using and explicit @list or @set will just be the source of confusion for many users, and it should be avoided.

My preference goes to @darobin's proposal. The added advantage is that it indeed makes it possible (now or in the future) to add additional properties to each accessModeSufficient option. As an example, when I first read through the examples, it was not really clear to me what the various accessModeSufficient options meant, for example for Moby Dick and, actually, the example did add some explanatory note in some cases to make it more clear. Well, adding those explanatory notes to the model itself is a good idea (just as the example of @darobin shows). But I agree with @clapierre that the accessibilitySummary is still necessary.

That being said, model wise there is no real difference between @darobin's model and @danbri's proposal based on schema lists. The latter uses ItemList (@danbri, your example used ListItem, isn't that a bug, shouldn't it be ItemList?) instead of AccessModality for the type, and itemListElement instead of requiredModality for the array; that is all! It has the same advantage as @darobin's approach but uses a generic structure instead of a specific one. I am not sure whether that is an advantage or not (do schema processors make something special with this?). Actually, we may also combine these: we could define AccessModality as a subclass of ItemList and then the only modification in @darobin's example is to use itemListElement...

iherman commented Jul 8, 2016

Just as a side remark: it is indeed correct that RDF/OWL does use RDF Lists when, in fact, unordered collections are required model wise (see, e.g., the Class Disjointness Example in the OWL Primer). This could be considered a hack; I am not sure it is a good idea to make this hack explicit, because it just leads to misunderstandings. In other words, I think using and explicit @list or @set will just be the source of confusion for many users, and it should be avoided.

My preference goes to @darobin's proposal. The added advantage is that it indeed makes it possible (now or in the future) to add additional properties to each accessModeSufficient option. As an example, when I first read through the examples, it was not really clear to me what the various accessModeSufficient options meant, for example for Moby Dick and, actually, the example did add some explanatory note in some cases to make it more clear. Well, adding those explanatory notes to the model itself is a good idea (just as the example of @darobin shows). But I agree with @clapierre that the accessibilitySummary is still necessary.

That being said, model wise there is no real difference between @darobin's model and @danbri's proposal based on schema lists. The latter uses ItemList (@danbri, your example used ListItem, isn't that a bug, shouldn't it be ItemList?) instead of AccessModality for the type, and itemListElement instead of requiredModality for the array; that is all! It has the same advantage as @darobin's approach but uses a generic structure instead of a specific one. I am not sure whether that is an advantage or not (do schema processors make something special with this?). Actually, we may also combine these: we could define AccessModality as a subclass of ItemList and then the only modification in @darobin's example is to use itemListElement...

@jaygray0919

This comment has been minimized.

Show comment
Hide comment
@jaygray0919

jaygray0919 Jul 8, 2016

Agree with @iherman. May I repeat this open issue: #1170. It is one example of setting order for a list per Ivan's discussion. It also presents a real problem with the domain of ListItem nextItem. IMHO it's a simple, non-controversial proposal. However, we'll defer to the heavyweights on this thread.

Agree with @iherman. May I repeat this open issue: #1170. It is one example of setting order for a list per Ivan's discussion. It also presents a real problem with the domain of ListItem nextItem. IMHO it's a simple, non-controversial proposal. However, we'll defer to the heavyweights on this thread.

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jul 8, 2016

Contributor

@iherman I agree that my proposal is very close to @danbri's (that's on purpose :) but the ItemList/ListItem issue is part of why I prefer a specialised syntax: since those objects are simultaneously items in a list and lists of items, both classes could in fact apply… I find that confusing (but maybe it's just me). Also, the various list things I would expect to be @list in the context, whereas in minting our properties we could make them @set.

Contributor

darobin commented Jul 8, 2016

@iherman I agree that my proposal is very close to @danbri's (that's on purpose :) but the ItemList/ListItem issue is part of why I prefer a specialised syntax: since those objects are simultaneously items in a list and lists of items, both classes could in fact apply… I find that confusing (but maybe it's just me). Also, the various list things I would expect to be @list in the context, whereas in minting our properties we could make them @set.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 21, 2016

Contributor

To address an earlier point, yes I did screw up an example somewhere and wrote ItemList for ListItem or vice-versa; I thought I'd fixed all occurances of that but apparently not.

Following this discussion, I am going off the idea of using syntax-specific lists, or ItemList, but perhaps a custom subtype of it so we can (in theory at least) re-use numberOfItems as a simple checking mechanism.

Contributor

danbri commented Jul 21, 2016

To address an earlier point, yes I did screw up an example somewhere and wrote ItemList for ListItem or vice-versa; I thought I'd fixed all occurances of that but apparently not.

Following this discussion, I am going off the idea of using syntax-specific lists, or ItemList, but perhaps a custom subtype of it so we can (in theory at least) re-use numberOfItems as a simple checking mechanism.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Jul 27, 2016

@danbri or @chaals, can you let us know the specific syntax you would like to recommend? I can then use that to generate examples for the elements on the pending page.

@danbri or @chaals, can you let us know the specific syntax you would like to recommend? I can then use that to generate examples for the elements on the pending page.

@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Aug 5, 2016

This issue seems to have stalled... Putting my hat of IDPF EPUB WG on, there is a certain level of urgency to solve it. Indeed, the WG is on its way to wind down, and this issue is important to close the work related to accessibility.

If I look at my comment, @darobin's answer, as well as @danbri's answer, can we agree that @darobin's original proposal wins? I guess the next step would be for @madeleinerothberg to finalize the examples using the final term set and structure, and to add the terms, with their proper definition, to the schema.org tree...

iherman commented Aug 5, 2016

This issue seems to have stalled... Putting my hat of IDPF EPUB WG on, there is a certain level of urgency to solve it. Indeed, the WG is on its way to wind down, and this issue is important to close the work related to accessibility.

If I look at my comment, @darobin's answer, as well as @danbri's answer, can we agree that @darobin's original proposal wins? I guess the next step would be for @madeleinerothberg to finalize the examples using the final term set and structure, and to add the terms, with their proper definition, to the schema.org tree...

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 5, 2016

Contributor

I'm happy to work from @darobin 's i.e. #1100 (comment) but I'm still concerned that dropping triples radically changes the meaning of the data. Can we have some kind of count or other metadata so (as with the old OWL stuff) it is possible to check that all the constraints have been communicated?

Contributor

danbri commented Aug 5, 2016

I'm happy to work from @darobin 's i.e. #1100 (comment) but I'm still concerned that dropping triples radically changes the meaning of the data. Can we have some kind of count or other metadata so (as with the old OWL stuff) it is possible to check that all the constraints have been communicated?

@iherman

This comment has been minimized.

Show comment
Hide comment
@iherman

iherman Aug 6, 2016

I'm still concerned that dropping triples radically changes the meaning of the data. Can we have some kind of count or other metadata so (as with the old OWL stuff) it is possible to check that all the constraints have been communicated?

@danbri can you elaborate? I am not sure I understand your concerns (although @madeleinerothberg or @clapierre may, they are more versed in the details than I am).

iherman commented Aug 6, 2016

I'm still concerned that dropping triples radically changes the meaning of the data. Can we have some kind of count or other metadata so (as with the old OWL stuff) it is possible to check that all the constraints have been communicated?

@danbri can you elaborate? I am not sure I understand your concerns (although @madeleinerothberg or @clapierre may, they are more versed in the details than I am).

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 6, 2016

Contributor

@iherman they didn't raise it, I brought this up. It's hard to articulate, so I'll pick a different and loosely analogous scenario:

Consider trying to express something like "Entrance criteria for Dan's nightclub: dresscode is: shoes-or-footcovering, trousers-or-skirt, shirt-or-equiv", i.e. you can get in if you meet these 3 points.

Because of the way RDF-based languages work, with AND'd independent triples, if some collection of triples are believed to be true, you ought to also believe any subset. And such subsets can be legitimately acquired e.g. by SPARQL querying a larger collection. So the concern is equivalent to worrying that some schema designs for this situation would make it possible to end up with a subset that is "also true" at one level but misleading, e.g. you'd convince yourself you could get entry to the fictional nightclub while only wearing shoes-or-footcovering.

That's why I brought up the otherwise annoying RDF list construction: it is organized in a way that makes it obvious when you have a truncated list. A check/count (e.g. a custom property like "numDresscodeConstraints: 3" would be similar. OWL used the list structure because it has a lot of machinery for defining class membership rules in terms of complicated criteria.

Maybe I'm making a fuss about nothing here, I will admit that the concern seems a little theoretical. Copying @rvguha who may have some perspective.

Contributor

danbri commented Aug 6, 2016

@iherman they didn't raise it, I brought this up. It's hard to articulate, so I'll pick a different and loosely analogous scenario:

Consider trying to express something like "Entrance criteria for Dan's nightclub: dresscode is: shoes-or-footcovering, trousers-or-skirt, shirt-or-equiv", i.e. you can get in if you meet these 3 points.

Because of the way RDF-based languages work, with AND'd independent triples, if some collection of triples are believed to be true, you ought to also believe any subset. And such subsets can be legitimately acquired e.g. by SPARQL querying a larger collection. So the concern is equivalent to worrying that some schema designs for this situation would make it possible to end up with a subset that is "also true" at one level but misleading, e.g. you'd convince yourself you could get entry to the fictional nightclub while only wearing shoes-or-footcovering.

That's why I brought up the otherwise annoying RDF list construction: it is organized in a way that makes it obvious when you have a truncated list. A check/count (e.g. a custom property like "numDresscodeConstraints: 3" would be similar. OWL used the list structure because it has a lot of machinery for defining class membership rules in terms of complicated criteria.

Maybe I'm making a fuss about nothing here, I will admit that the concern seems a little theoretical. Copying @rvguha who may have some perspective.

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Sep 8, 2016

@danbri BUT...the description on the ItemList:itemListElement shows enclosing quotes around each element in the List however...

For itemListElement values, you can use simple strings (e.g. "Peter", "Paul", "Mary"), existing entities, or use ListItem.

Is the description saying it is ok to use my proposed simple form with "Peter, Paul, Mary" ?

Example:
{
"@context": "http://schema.org",
"@type": "ItemList",
"@url": "http://en.wikipedia.org/wiki/Billboard_200",
"name": "Top music artists",
"description": "The artists with the most cumulative weeks at number one according to Billboard 200",
"itemListElement": "Prince, Michael Jackson, Rolling Stones"
}

TODO ? We don't seem to have the simple Text List case in any of 1-6 examples on ItemList, so I think that is throwing me off and probably others as well. Let's fix that if we can, and give the simple List form (only 1 pair of enclosing quotes with comma separating your elements) in the description for itemListElement.

thadguidry commented Sep 8, 2016

@danbri BUT...the description on the ItemList:itemListElement shows enclosing quotes around each element in the List however...

For itemListElement values, you can use simple strings (e.g. "Peter", "Paul", "Mary"), existing entities, or use ListItem.

Is the description saying it is ok to use my proposed simple form with "Peter, Paul, Mary" ?

Example:
{
"@context": "http://schema.org",
"@type": "ItemList",
"@url": "http://en.wikipedia.org/wiki/Billboard_200",
"name": "Top music artists",
"description": "The artists with the most cumulative weeks at number one according to Billboard 200",
"itemListElement": "Prince, Michael Jackson, Rolling Stones"
}

TODO ? We don't seem to have the simple Text List case in any of 1-6 examples on ItemList, so I think that is throwing me off and probably others as well. Let's fix that if we can, and give the simple List form (only 1 pair of enclosing quotes with comma separating your elements) in the description for itemListElement.

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Sep 8, 2016

Contributor

The comma-separated list is going to be error-prone. As an example, for top artist, should I interpret "Peter, Paul, and Mary" as 3 entities or 1?

While I agree we should put the burden on data consumers to do the heavy lifting, we shouldn't make their work impossible. CSV-style quoting is rather ugly.

Contributor

vholland commented Sep 8, 2016

The comma-separated list is going to be error-prone. As an example, for top artist, should I interpret "Peter, Paul, and Mary" as 3 entities or 1?

While I agree we should put the burden on data consumers to do the heavy lifting, we shouldn't make their work impossible. CSV-style quoting is rather ugly.

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Sep 8, 2016

Contributor

I am a bit wary of overloading commas that way. e.g., "Martin Luther King,
Jr."

guha

On Thu, Sep 8, 2016 at 12:25 PM, vholland notifications@github.com wrote:

The comma-separated list is going to be error-prone. As an example, for
top artist, should I interpret "Peter, Paul, and Mary" as 3 entities or 1?

While I agree we should put the burden on data consumers to do the heavy
lifting, we shouldn't make their work impossible. CSV-style quoting is
rather ugly.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCg_e5Pa1m-e7_YJ27BMYXiDglm8Tks5qoGEbgaJpZM4IF9Yn
.

Contributor

rvguha commented Sep 8, 2016

I am a bit wary of overloading commas that way. e.g., "Martin Luther King,
Jr."

guha

On Thu, Sep 8, 2016 at 12:25 PM, vholland notifications@github.com wrote:

The comma-separated list is going to be error-prone. As an example, for
top artist, should I interpret "Peter, Paul, and Mary" as 3 entities or 1?

While I agree we should put the burden on data consumers to do the heavy
lifting, we shouldn't make their work impossible. CSV-style quoting is
rather ugly.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCg_e5Pa1m-e7_YJ27BMYXiDglm8Tks5qoGEbgaJpZM4IF9Yn
.

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Sep 8, 2016

Contributor

@thadguidry No, the description says it would be okay to have:

itemListElement: ["Peter", "Paul", "Mary"]

instead of

itemListElement: [
  {
    "@type": "ListItem",
    "item": { "@type": "Person", "givenName": "Peter" }
  },
  {
    "@type": "ListItem",
    "item": { "@type": "Person", "givenName": "Paul" }
  },
  {
    "@type": "ListItem",
    "item": { "@type": "Person", "givenName": "Mary" }
  }
]

(Not that they're equivalent, but both are allowed.)

Processing commas (or any other syntax inside literals) is not for schema.org to decide, that's up to the individual syntaxes. Also, I would like to get on the record that it is a really, really bad idea that will collide with large amounts of existing content. It also doesn't buy much compared to the first example above.

Contributor

darobin commented Sep 8, 2016

@thadguidry No, the description says it would be okay to have:

itemListElement: ["Peter", "Paul", "Mary"]

instead of

itemListElement: [
  {
    "@type": "ListItem",
    "item": { "@type": "Person", "givenName": "Peter" }
  },
  {
    "@type": "ListItem",
    "item": { "@type": "Person", "givenName": "Paul" }
  },
  {
    "@type": "ListItem",
    "item": { "@type": "Person", "givenName": "Mary" }
  }
]

(Not that they're equivalent, but both are allowed.)

Processing commas (or any other syntax inside literals) is not for schema.org to decide, that's up to the individual syntaxes. Also, I would like to get on the record that it is a really, really bad idea that will collide with large amounts of existing content. It also doesn't buy much compared to the first example above.

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Sep 8, 2016

All - awesome. Everyone agrees, bad idea of simple comma separated list for itemListElement. And I also thought it was a bad idea sorta and saw the documentation issues. And why I brought it up, which was I saw sites doing those kind of things. Probably because of our weak example of it and the wording in the description.

So...

The good idea is now to just clarify with a good example and put inside the description that you should use the [ ] array holder. And also note that 'it is a bad idea to use a simple comma separated list, instead use the [ ] array holder, such as itemListElement: ["Peter", "Paul", "Mary"] or something to that effect.

All - awesome. Everyone agrees, bad idea of simple comma separated list for itemListElement. And I also thought it was a bad idea sorta and saw the documentation issues. And why I brought it up, which was I saw sites doing those kind of things. Probably because of our weak example of it and the wording in the description.

So...

The good idea is now to just clarify with a good example and put inside the description that you should use the [ ] array holder. And also note that 'it is a bad idea to use a simple comma separated list, instead use the [ ] array holder, such as itemListElement: ["Peter", "Paul", "Mary"] or something to that effect.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Sep 8, 2016

Do we need to address the issue that came up earlier on this thread, that "list" implies that the order matters while "set" does not? For the accessModeSufficient use case, order does not matter.

Do we need to address the issue that came up earlier on this thread, that "list" implies that the order matters while "set" does not? For the accessModeSufficient use case, order does not matter.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 8, 2016

Contributor

We ought to be explicit and say that the ordering is not relevant.

Contributor

danbri commented Sep 8, 2016

We ought to be explicit and say that the ordering is not relevant.

@tmarshbing

This comment has been minimized.

Show comment
Hide comment
@tmarshbing

tmarshbing Sep 12, 2016

Can we not use http://schema.org/itemListOrder of "Unordered" if we want to be explicit?

Can we not use http://schema.org/itemListOrder of "Unordered" if we want to be explicit?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 12, 2016

Contributor

Good point. So let's be explicit in the property definitions that the itemListOrder is "Unordered", rather than have the instance data need to express it.

Contributor

danbri commented Sep 12, 2016

Good point. So let's be explicit in the property definitions that the itemListOrder is "Unordered", rather than have the instance data need to express it.

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Sep 21, 2016

Contributor

Where are we on this? Would be good to get it out in the next version.

guha

On Tue, Sep 6, 2016 at 12:26 PM, Dan Brickley notifications@github.com
wrote:

I may even be saying that this could be a good idea for the mainstream
schema.org representation. However the rough consensus here seemed to be
that I was making a bit of a fuss over nothing regarding concerns about
atomic vs composite meaning and repeated properties. Maybe @rvguha
https://github.com/rvguha can figure out what I was on about and jump
in here?

In terms of syntax, the idea is that

"requiredModality": ["auditory", "visual"],

could become just

"requiredModality": "auditory, visual" ...

...which packs an entire list in a single property, a behaviour which
simultaneously makes it difficult to process w.r.t. the sub-components
(except via clumsy regular expressions), but also safe from being
fragmented into sub-graphs with accidental meaning change.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCnQWhuHX9zVO18WtfGkpOTc8XH-Kks5qnb5IgaJpZM4IF9Yn
.

Contributor

rvguha commented Sep 21, 2016

Where are we on this? Would be good to get it out in the next version.

guha

On Tue, Sep 6, 2016 at 12:26 PM, Dan Brickley notifications@github.com
wrote:

I may even be saying that this could be a good idea for the mainstream
schema.org representation. However the rough consensus here seemed to be
that I was making a bit of a fuss over nothing regarding concerns about
atomic vs composite meaning and repeated properties. Maybe @rvguha
https://github.com/rvguha can figure out what I was on about and jump
in here?

In terms of syntax, the idea is that

"requiredModality": ["auditory", "visual"],

could become just

"requiredModality": "auditory, visual" ...

...which packs an entire list in a single property, a behaviour which
simultaneously makes it difficult to process w.r.t. the sub-components
(except via clumsy regular expressions), but also safe from being
fragmented into sub-graphs with accidental meaning change.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCnQWhuHX9zVO18WtfGkpOTc8XH-Kks5qnb5IgaJpZM4IF9Yn
.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 21, 2016

Contributor

A number of us are at W3C TPAC this week, and aspire to meet towards finishing this work but haven't managed it yet...

Contributor

danbri commented Sep 21, 2016

A number of us are at W3C TPAC this week, and aspire to meet towards finishing this work but haven't managed it yet...

@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Sep 21, 2016

Hi Dan, George, Avneesh and I are here and will talk with you after this meeting we are all in in RDF Namespaces. :)

Hi Dan, George, Avneesh and I are here and will talk with you after this meeting we are all in in RDF Namespaces. :)

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 21, 2016

Contributor

We are now in a room. Ping @chaals though assume you are busy with webplatform.

Contributor

danbri commented Sep 21, 2016

We are now in a room. Ping @chaals though assume you are busy with webplatform.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 21, 2016

Contributor

Notes from meeting:

For example, a digital book that is mostly text with some simple images that
has alt text associated with the image. In this case, the
accessModeSufficient would be 'textual' because the entire book can be understood
or perceived by a person using assistive technology.

If the book did not have alt text, we would instead say that the accessModeSufficient
had two values, which had two values (expressed as an [[ItemList]], 'visual' and
'textual'). The order of the list does not matter, and the intent is to express that
the content is difficult or impossible to use without each of these access modalities.

Not to be used:

Such distinctions naturally have a degree of subjectivity. While this terminology
can be used for general-purpose descriptions of content, it is also
applicable to tools and environments that personalize content to the accessibility
needs of specific users and tasks.

RESOLVED:

  • happy with ItemList
  • action: dan to update examples to use itemlist by friday
  • need to add IDPF and/or Daily Wiki links as explanation.
  • considered renaming sufficientAccessMode but declined to, due to related standards
    at IDPF and IMS using the current terminology.
Contributor

danbri commented Sep 21, 2016

Notes from meeting:

For example, a digital book that is mostly text with some simple images that
has alt text associated with the image. In this case, the
accessModeSufficient would be 'textual' because the entire book can be understood
or perceived by a person using assistive technology.

If the book did not have alt text, we would instead say that the accessModeSufficient
had two values, which had two values (expressed as an [[ItemList]], 'visual' and
'textual'). The order of the list does not matter, and the intent is to express that
the content is difficult or impossible to use without each of these access modalities.

Not to be used:

Such distinctions naturally have a degree of subjectivity. While this terminology
can be used for general-purpose descriptions of content, it is also
applicable to tools and environments that personalize content to the accessibility
needs of specific users and tasks.

RESOLVED:

  • happy with ItemList
  • action: dan to update examples to use itemlist by friday
  • need to add IDPF and/or Daily Wiki links as explanation.
  • considered renaming sufficientAccessMode but declined to, due to related standards
    at IDPF and IMS using the current terminology.
@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Sep 21, 2016

Here is a link to our wiki definition of AccessMode, AccessModeSufficient, and AccessibilitySummary.

https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

Here is a link to our wiki definition of AccessMode, AccessModeSufficient, and AccessibilitySummary.

https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 21, 2016

Contributor

Also resolved:

  • We will remove this list: "colorDependent, chartOnVisual, chemOnVisual, diagramOnVisual, mathOnVisual, musicOnVisual, textOnVisual." from accessMode and replace it with a link to a document giving these or similar, perhaps/ideally a Wiki that can evolve.
  • accessibilitySummary - it could be a short textual block inline or a link to a document/page. And, further, that future application of this property to physical accessibility would be reasonable.
Contributor

danbri commented Sep 21, 2016

Also resolved:

  • We will remove this list: "colorDependent, chartOnVisual, chemOnVisual, diagramOnVisual, mathOnVisual, musicOnVisual, textOnVisual." from accessMode and replace it with a link to a document giving these or similar, perhaps/ideally a Wiki that can evolve.
  • accessibilitySummary - it could be a short textual block inline or a link to a document/page. And, further, that future application of this property to physical accessibility would be reasonable.
@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Sep 21, 2016

Contributor

Regarding the list of terms I would personally prefer it if they stayed in schema.org to benefit from broader review. Our interest in this topic stems from the fact that we tried to use the existing accessibility description features and based on the documentation we couldn't figure it out unambiguously — so we gave up.

I am leery that moving things to an external wiki punts.

Contributor

darobin commented Sep 21, 2016

Regarding the list of terms I would personally prefer it if they stayed in schema.org to benefit from broader review. Our interest in this topic stems from the fact that we tried to use the existing accessibility description features and based on the documentation we couldn't figure it out unambiguously — so we gave up.

I am leery that moving things to an external wiki punts.

@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Sep 22, 2016

Dan asked for our IDPF EPUB 3.1 Timeline where we will also be releasing the Accessibility Guidelines 1.0 which relies on the Schema.org metadata.

Timeline (ideal world):
Final editors draft: 1 August
Elevation to Public Draft status : 1 September
Elevation to Proposed status and IP review (45 days) 1 October
Submission of spec with implementation roadmap, membership vote (30 Days) 15 November
(BOD may decide to postpone vote depending on implementation status)
Vote concludes: 15 December

Dan asked for our IDPF EPUB 3.1 Timeline where we will also be releasing the Accessibility Guidelines 1.0 which relies on the Schema.org metadata.

Timeline (ideal world):
Final editors draft: 1 August
Elevation to Public Draft status : 1 September
Elevation to Proposed status and IP review (45 days) 1 October
Submission of spec with implementation roadmap, membership vote (30 Days) 15 November
(BOD may decide to postpone vote depending on implementation status)
Vote concludes: 15 December

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 22, 2016

Contributor

@darobin - as @clapierre points out - we have a limited time window, I'd like to get these basics done asap. Currently e.g. 'chemOnVisual' (within schema.org) has no kind of proposed definition (or thing to link to) and just serves to confuse the majority of readers.

Contributor

danbri commented Sep 22, 2016

@darobin - as @clapierre points out - we have a limited time window, I'd like to get these basics done asap. Currently e.g. 'chemOnVisual' (within schema.org) has no kind of proposed definition (or thing to link to) and just serves to confuse the majority of readers.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Sep 26, 2016

All of these decisions look fine to me except that I would argue to keep "colorDependent" in the accessMode vocabulary. It is used to flag material which would be difficult to use for someone with color blindness, which is one of the more common visual impairments.

In addition, I would argue to keep textOnVisual, which has been a feature of access mode going back several iterations in IMS (with the name textOnImage). Again, this is a common problem for accessibility, when text is included in an image and cannot be adjusted visually or read aloud by TTS.

The proposal to add accessMode and its vocabulary doesn't currently include definitions for each term, but as part of this process we will create documentation that includes those definitions and any other materials that the community would like. Would that help alleviate the concerns about these terms?

All of these decisions look fine to me except that I would argue to keep "colorDependent" in the accessMode vocabulary. It is used to flag material which would be difficult to use for someone with color blindness, which is one of the more common visual impairments.

In addition, I would argue to keep textOnVisual, which has been a feature of access mode going back several iterations in IMS (with the name textOnImage). Again, this is a common problem for accessibility, when text is included in an image and cannot be adjusted visually or read aloud by TTS.

The proposal to add accessMode and its vocabulary doesn't currently include definitions for each term, but as part of this process we will create documentation that includes those definitions and any other materials that the community would like. Would that help alleviate the concerns about these terms?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 26, 2016

Contributor

@madeleinerothberg can you point us to definitions for these. Currently the draft definitions are just a list of mysterious (to the uninitiated...) strings. Is there an URL elsewhere that e.g. 'textOnVisual' should link to, or a short phrase defining it?

Contributor

danbri commented Sep 26, 2016

@madeleinerothberg can you point us to definitions for these. Currently the draft definitions are just a list of mysterious (to the uninitiated...) strings. Is there an URL elsewhere that e.g. 'textOnVisual' should link to, or a short phrase defining it?

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Sep 26, 2016

ColorDependent and textOnImage are both defined in the IMS Access for All v3 public draft in the Data Element Specification document, linked below. We can use these short definitions or improve them, as seems best to this community. We will post additional definitions so that all terms in the schema vocabularies have definitions.

Definition of colorDependent from IMS is "Information is conveyed that requires the ability to perceive colour." (It lists the term as "colour", but IMS has decided to adopt the schema.org suggestion of colorDependent since that is a much clearer name; updates to be published soon.)
https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719848

Definition of textOnImage from IMS is "Information is conveyed using text where the text is embedded in an image."
https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719895

ColorDependent and textOnImage are both defined in the IMS Access for All v3 public draft in the Data Element Specification document, linked below. We can use these short definitions or improve them, as seems best to this community. We will post additional definitions so that all terms in the schema vocabularies have definitions.

Definition of colorDependent from IMS is "Information is conveyed that requires the ability to perceive colour." (It lists the term as "colour", but IMS has decided to adopt the schema.org suggestion of colorDependent since that is a much clearer name; updates to be published soon.)
https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719848

Definition of textOnImage from IMS is "Information is conveyed using text where the text is embedded in an image."
https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_DESinfoModel_v1p0pd.html#_Toc323719895

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Sep 28, 2016

Is this what everyone has in mind for ItemList syntax?

Example 1

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "accessMode": ["auditory", "visual"],
  "accessibilityFeature": ["audioDescription", "captions"],
  "accessModeSufficient": [ 
    {
      "@type": "ItemList", 
      "itemListElement": ["textual", "visual"], 
      "description": "Closed captioning"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory"], 
      "description": "Audio description"
    }
  ],
  "accessibilitySummary": "Captions provided in English; short scenes in French have English subtitles instead."
}

Example 2

{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ 
    {
      "@type": "ItemList", 
      "itemListElement": ["textual"], 
      "description": "See the text"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["textual", "visual"], 
      "description": "See the text and images"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory"], 
      "description": "Hear the text and image descriptions"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory", "visual"], 
      "description": "Hear the text and see the images"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory", "visual", "textual"], 
      "description": "Hear the text and see the text and images"
    }
  ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}

Is this what everyone has in mind for ItemList syntax?

Example 1

{
  "@context": "http://schema.org/",
  "@type": "Movie",
  "accessMode": ["auditory", "visual"],
  "accessibilityFeature": ["audioDescription", "captions"],
  "accessModeSufficient": [ 
    {
      "@type": "ItemList", 
      "itemListElement": ["textual", "visual"], 
      "description": "Closed captioning"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory"], 
      "description": "Audio description"
    }
  ],
  "accessibilitySummary": "Captions provided in English; short scenes in French have English subtitles instead."
}

Example 2

{
  "@context": "http://schema.org/",
  "@type": "Book",
  "name": "Alice in Wonderland",
  "accessMode": ["auditory", "textual", "visual"],
  "accessibilityFeature": ["alternativeText", "synchronizedAudioText"],
  "accessModeSufficient": [ 
    {
      "@type": "ItemList", 
      "itemListElement": ["textual"], 
      "description": "See the text"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["textual", "visual"], 
      "description": "See the text and images"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory"], 
      "description": "Hear the text and image descriptions"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory", "visual"], 
      "description": "Hear the text and see the images"
    },
    {
      "@type": "ItemList", 
      "itemListElement": ["auditory", "visual", "textual"], 
      "description": "Hear the text and see the text and images"
    }
  ],
  "accessibilitySummary": "Short descriptions are provided; long descriptions of the images are not needed for most readers."
}
@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Sep 30, 2016

Hi @danbri , we are about to go into IP review with the IDPF next week. It would really be helpful to have this hammered out and if possible some URI's we can point to when we submit our documents for review.
Thanks

clapierre commented Sep 30, 2016

Hi @danbri , we are about to go into IP review with the IDPF next week. It would really be helpful to have this hammered out and if possible some URI's we can point to when we submit our documents for review.
Thanks

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Oct 3, 2016

Contributor

Ok, I think we're pretty much there.

  • First - @madeleinerothberg 's updated examples with ItemList look good to me.
  • Second - I think there are some minor updates to pending.webschemas.org that need tweaking following the TPAC meeting.
  • Third - @madeleinerothberg provided links/details for some of the coded values.

I'll work on getting the webschemas pending version in a form you can all say "looks good" to, tomorrow. After which I will move them directly out of "pending" into the candidate v3.2 release for final review and publication. Since we have had quite detailed discussions involved schema.org steering group members here there should be no big hurdles beyond that.

Contributor

danbri commented Oct 3, 2016

Ok, I think we're pretty much there.

  • First - @madeleinerothberg 's updated examples with ItemList look good to me.
  • Second - I think there are some minor updates to pending.webschemas.org that need tweaking following the TPAC meeting.
  • Third - @madeleinerothberg provided links/details for some of the coded values.

I'll work on getting the webschemas pending version in a form you can all say "looks good" to, tomorrow. After which I will move them directly out of "pending" into the candidate v3.2 release for final review and publication. Since we have had quite detailed discussions involved schema.org steering group members here there should be no big hurdles beyond that.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Oct 3, 2016

Contributor

Looks good to me, let's ship :)

I'd be grateful if someone can write up an example as RDFa or microdata, not because I think it is a majority use case - although it seems like in catalogs it makes sense to serialise the data out in readable form - but to check that it matches my mental model…

Contributor

chaals commented Oct 3, 2016

Looks good to me, let's ship :)

I'd be grateful if someone can write up an example as RDFa or microdata, not because I think it is a majority use case - although it seems like in catalogs it makes sense to serialise the data out in readable form - but to check that it matches my mental model…

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Oct 18, 2016

Pinging as a reminder that the new examples need to be implemented in the pending pages for accessMode and accessModeSufficient.

Pinging as a reminder that the new examples need to be implemented in the pending pages for accessMode and accessModeSufficient.

danbri added a commit that referenced this issue Oct 18, 2016

Updated examples for #1100
accessibilityFeature is already in schema.org

These really ought to have better non-markup summaries, and
RDFa/Microdata versions.
@danbri

This comment has been minimized.

Show comment
Hide comment
Contributor

danbri commented Oct 18, 2016

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Oct 18, 2016

Contributor

Odd, it works for me. Is http://pending.webschemas.org/accessModeSufficient
still 404 for you?

There are sometimes delays with the site due to multiple servers, caching
etc but it ought to be there for everyone by now. Copying @RichardWallis
who may have a theory if not.

On 18 October 2016 at 19:48, Charles LaPierre notifications@github.com
wrote:

hi @danbri https://github.com/danbri was the point of the link to see a
page not found in pending :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKZGZlZo-DdXoij8rKDtX3yerl_tvrGks5q1QZtgaJpZM4IF9Yn
.

Contributor

danbri commented Oct 18, 2016

Odd, it works for me. Is http://pending.webschemas.org/accessModeSufficient
still 404 for you?

There are sometimes delays with the site due to multiple servers, caching
etc but it ought to be there for everyone by now. Copying @RichardWallis
who may have a theory if not.

On 18 October 2016 at 19:48, Charles LaPierre notifications@github.com
wrote:

hi @danbri https://github.com/danbri was the point of the link to see a
page not found in pending :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1100 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKZGZlZo-DdXoij8rKDtX3yerl_tvrGks5q1QZtgaJpZM4IF9Yn
.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Oct 18, 2016

At that address, I see boilerplate for 4 examples, but the first one is still the older syntax with no item list. (The other three all say "See also https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org".)

At that address, I see boilerplate for 4 examples, but the first one is still the older syntax with no item list. (The other three all say "See also https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org".)

@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Oct 18, 2016

Yes I believe it was a caching issue as it is working now. Thanks @danbri
So does this mean this has been accepted and will be in the next release of Schema.org?
We will need links we can link our spec to when this moves from pending to its final resting place.

Yes I believe it was a caching issue as it is working now. Thanks @danbri
So does this mean this has been accepted and will be in the next release of Schema.org?
We will need links we can link our spec to when this moves from pending to its final resting place.

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Oct 26, 2016

@danbri I still don't see the new itemlist examples on the pending page -- either on webschemas.org or schema.org. Should those be visible now? See attached image.

pending_example_wrong

@danbri I still don't see the new itemlist examples on the pending page -- either on webschemas.org or schema.org. Should those be visible now? See attached image.

pending_example_wrong

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Oct 27, 2016

Contributor

You should see them on http://pending.webschemas.org/accessMode

These will get pushed to the stable-released-snapshots version of the schema.org site with our next release.

Contributor

danbri commented Oct 27, 2016

You should see them on http://pending.webschemas.org/accessMode

These will get pushed to the stable-released-snapshots version of the schema.org site with our next release.

@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Oct 27, 2016

Hi @danbri Yes I do see this but the Example # 1 JSON-LD doesn't look right compared with Examples # 2, # 3, # 4 etc.. which do have itemListElement, but example # 1 looks different. I didn't realize that the JSON-LD tabs were specific to each example as they were all pointing to the same See also https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org in the "Without-Markup" tab.

IE
Example # 1 JSON-DL tab has
<script type="application/ld+json"> { "@context": "http://schema.org/", "@type": "Book", "name": "Some graphic novel", "accessMode": ["textual", "visual"], "accessModeSufficient": ["textual", "visual"], "accessibilitySummary": "Visual elements are not described." } </script>

whereas
Example # 2's JSON-LD tab has

{
"@context": "http://schema.org/",
"@type": "Movie",
"accessMode": ["auditory", "visual"],
"accessibilityFeature": ["audioDescription", "captions"],
"accessModeSufficient": [
{
"@type": "ItemList",
"itemListElement": ["textual", "visual"],
"description": "Closed captioning"
},
{
"@type": "ItemList",
"itemListElement": ["auditory"],
"description": "Audio description"
}
],
"accessibilitySummary": "Captions provided in English; short scenes in French have English subtitles instead."
}

clapierre commented Oct 27, 2016

Hi @danbri Yes I do see this but the Example # 1 JSON-LD doesn't look right compared with Examples # 2, # 3, # 4 etc.. which do have itemListElement, but example # 1 looks different. I didn't realize that the JSON-LD tabs were specific to each example as they were all pointing to the same See also https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org in the "Without-Markup" tab.

IE
Example # 1 JSON-DL tab has
<script type="application/ld+json"> { "@context": "http://schema.org/", "@type": "Book", "name": "Some graphic novel", "accessMode": ["textual", "visual"], "accessModeSufficient": ["textual", "visual"], "accessibilitySummary": "Visual elements are not described." } </script>

whereas
Example # 2's JSON-LD tab has

{
"@context": "http://schema.org/",
"@type": "Movie",
"accessMode": ["auditory", "visual"],
"accessibilityFeature": ["audioDescription", "captions"],
"accessModeSufficient": [
{
"@type": "ItemList",
"itemListElement": ["textual", "visual"],
"description": "Closed captioning"
},
{
"@type": "ItemList",
"itemListElement": ["auditory"],
"description": "Audio description"
}
],
"accessibilitySummary": "Captions provided in English; short scenes in French have English subtitles instead."
}

@madeleinerothberg

This comment has been minimized.

Show comment
Hide comment
@madeleinerothberg

madeleinerothberg Oct 27, 2016

Thank you, @clapierre! I only looked at #1, which is wrong. I see the right stuff now in #2 and #3. #4 seems to be a repeat of #3. The same is true for accessModeSufficent also.

Thank you, @clapierre! I only looked at #1, which is wrong. I see the right stuff now in #2 and #3. #4 seems to be a repeat of #3. The same is true for accessModeSufficent also.

@clapierre

This comment has been minimized.

Show comment
Hide comment
@clapierre

clapierre Nov 16, 2016

Hello @danbri so we are getting close to the end of the IP review for the EPUB 3.1 Specification where we currently have the following:

Every conformant EPUB Publication must include the following [schema.org] accessibility metadata:
accessMode — the senses or faculties necessary to process or perceive the content (e.g., textual, visual, auditory, tactile).
accessibilityFeature — features and adaptations that increase the overall accessibility of the content (e.g., alternative text, extended descriptions, captions).
accessibilityHazard — any potential hazards that the content presents (e.g., flashing, motion simulation, sound).
accessibilitySummary — a human-readable summary of the overall accessibility, which includes a description of any known deficiencies (e.g., lack of extended descriptions, specific hazards).

How close are the new accessMode, accessModeSufficient and accessibilitySummary being adopted in Schema.org is there anything left to do?

Hello @danbri so we are getting close to the end of the IP review for the EPUB 3.1 Specification where we currently have the following:

Every conformant EPUB Publication must include the following [schema.org] accessibility metadata:
accessMode — the senses or faculties necessary to process or perceive the content (e.g., textual, visual, auditory, tactile).
accessibilityFeature — features and adaptations that increase the overall accessibility of the content (e.g., alternative text, extended descriptions, captions).
accessibilityHazard — any potential hazards that the content presents (e.g., flashing, motion simulation, sound).
accessibilitySummary — a human-readable summary of the overall accessibility, which includes a description of any known deficiencies (e.g., lack of extended descriptions, specific hazards).

How close are the new accessMode, accessModeSufficient and accessibilitySummary being adopted in Schema.org is there anything left to do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment