Re: [a11y-metadata-project] Re: accessibility RDFS write-up

Liddy,
   The issue of the searchable access modes is recorded as an open issue 
in the issue tracker, and there have been two proposals made. See 
http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#accessMode_and_accessibilityMode_subtype.2C_proposal_1 
(the second follows it).
As we've been spending our time to close on mediaFeature/accessFeature, 
we have not taken to this part yet. It is the logical next step in the 
process described and agreed to.

I would like to finalize the .7 draft, even with these known issues.  We 
have solidly addressed issues 1, 2, 3 and 8 from the issue tracker 
http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker at this 
point and we need to state that we're at a stable point with the items 
proposed, even if there are other issues still pending.  I do not 
diminish the import of those issues... we need to get this next stable 
point and move on and not revisit issues. I don't want us to change 
property names again after this, for example.

With two days of editorial work on the .7 specification behind me, I'll 
just reflect that the changes that we have made are actually somewhat 
cosmetic, simplifying and putting some terms, like largePrint into the 
vernacular. Most of the rest of this has been better explanations and 
groupings for what we've done.

So, let's make sure that we have the draft .7 of the specification as 
right as it can be, and then we can open it up for public comment once 
we have it in a steady state.
http://www.w3.org/wiki/WebSchemas/Accessibility I have the goal of 
having this available at the end of the day tomorrow, Friday, 11/8/13.

And then let's take up issues 6 and 7 on the list with passion after 
that. What is clear to me is that we different users need different sets 
of access modes, both the source and augmented, and our challenge is to 
find a way to represent both of them easily.

On 11/7/2013 1:54 PM, Liddy Nevile wrote:
> Colleagues,
>
> I have no intention of changing anything but how does it help a user 
> or search engine to know that there are some accessModes that can be 
> combined to provide the complete resource but it is not stated which 
> ones.
>
> For example, if the accessModes are video, text, auditory, how would 
> we know what is required to get all the content and how would I know 
> if I will be OK with just video and text or even just text? I 
> discussed this with Charles Nevile because I was curious about it and 
> heard little from the group.
>
> I  am pleased that at last there is a focus on this issue and suggest 
> that I am not doing anything new. Given the table as I have it, I 
> believe we are getting close to a minimal version of what we all talk 
> about, respect the principles, and have something implementable.
>
> I believe some are anxious about asking the metadata authors for the 
> resource to do some work in defining the combinations. I think that 
> most of the metadata on resources will either be written by experts or 
> derived and so this is not such a big problem as not providing the 
> user with a clear way of saying what they want.
>
> It is very important to have accessMode as a useful property; to have 
> accessFeatures so that users can think in terms of what they need; to 
> be able to make metadata-writing wizards that are easy to use; to have 
> clear rules for search/matching systems, etc and that all the time we 
> respect the user's individual choices.
>
> I have spent a lot of time trying to finess the tables - I was 
> surprised, for example, that if we have 'text' as I have it now, we 
> don't have to worry about the size or colour of the text, whereas for 
> captions printed on video etc, that is important.
>
> I really do welcome comments - so I am not being defensive but rather 
> wanting to know how to make this the best we can make it ...after so 
> many years of work.
>
> Liddy
>
> On 08/11/2013, at 12:33 AM, Madeleine Rothberg wrote:
>
>> Liddy,
>>
>> I am not disagreeing with your work on accessFeature. I agree that it 
>> would be useful to have a technical encoding of which accessModes 
>> each accessFeature contains and replaces. That is a separate topic. I 
>> do not think we will create that encoding in Schema, but we should 
>> create it somewhere.
>>
>> I am disagreeing with the new definition you have written for 
>> accessMode. I, and the rest of the group, do not think it makes sense 
>> to re-define accessMode to require the metadata author to do the 
>> computation of the combinations of access modes possible for a 
>> resource and its alternatives. We all feel that accessMode should 
>> continue to be defined as it has been. I suggest that a new field 
>> could be added called "accessModeCombinations" (or some much better 
>> name) that has the definition you have given.
>>
>> Some metadata authors may be capable of filling out the new field, 
>> but others will not. If authors correctly fill out accessMode and 
>> accessFeatures, an algorithm can deduce the values for the new field. 
>> As new resources are discovered that explicitly or serendipitously 
>> augment a resource, the number of ways to use it will grow, but the 
>> characteristics of the base resource will not change.
>>
>> -Madeleine
>>
>> From: Liddy Nevile <liddy@sunriseresearch.org>
>> Date: Thursday, November 7, 2013 12:16 AM
>> To: Matt Garrish <matt.garrish@bell.net>
>> Cc: Madeleine Rothberg <madeleine_rothberg@wgbh.org>, Dan Brickley 
>> <danbri@google.com>, Charles Myers <charlesm@benetech.org>, 
>> "a11y-metadata-project@googlegroups.com" 
>> <a11y-metadata-project@googlegroups.com>, "public-vocabs@w3.org" 
>> <public-vocabs@w3.org>
>> Subject: Re: [a11y-metadata-project] Re: accessibility RDFS write-up
>>
>>> Now I understand what is causing the problem.
>>>
>>> I am NOT inventing a new property --- I was simply organising the
>>> accessFeatures so that by stating an accessFeature of interest, it
>>> could quickly be seen what accessMode might be affected - ie doing
>>> what Chuck was doing but not having so much text in order to do it. I
>>> have changed the headings etc on the spreadhseets and think it might
>>> be better now - please have a look at this new version of the
>>> spreadsheets...
>>>
>>> Liddy
>>>
>>>
>>>
>>> On 07/11/2013, at 4:01 PM, Matt Garrish wrote:
>>>
>>> > I agree with Madeleine. This alteration makes it difficult to
>>> > understand/parse when an access mode has been inferred, or when it
>>> > reflects the actual nature of the content. For optimized discovery
>>> > and rendition selection from metadata in the epub package document,
>>> > we were looking for the unambiguous representation of the nature of
>>> > the content that accessMode was designed to give.
>>> >
>>> > It also directly changes an IMS property without changing its name,
>>> > which is worrisome. Where we have changed properties previously
>>> > (accessFeature combining properties), we've used different names to
>>> > avoid confusion.
>>> >
>>> > The whole +'ing of access modes is also lacking any explanation in
>>> > the given definition, which doesn't seem helpful for someone trying
>>> > to implement the property.
>>> >
>>> > Matt
>>> >
>>> > -----Original Message----- From: Madeleine Rothberg
>>> > Sent: Wednesday, November 06, 2013 11:19 PM
>>> > To: Liddy Nevile
>>> > Cc: Madeleine Rothberg ; Dan Brickley ; Charles Myers ; 
>>> a11y-metadata-project@googlegroups.com
>>> >  ; public-vocabs@w3.org
>>> > Subject: Re: [a11y-metadata-project] Re: accessibility RDFS write-up
>>> >
>>> > I think (and I believe others agree) that this is a new field,
>>> > computed from accessMode plus accessFeatures. The previous
>>> > definition of accessMode should remain in place, and the new field
>>> > you have suggested needs a more specific name.
>>> >
>>> > Madeleine
>>> >
>>> > On 2013-11-06, at 10:39 PM, "Liddy Nevile"
>>> > <liddy@sunriseresearch.org> wrote:
>>> >
>>> >> correct!
>>> >>
>>> >> I have put in what Charles Nevile and I understand to be what is
>>> >> wanted - and what he thinks will work (as far as I can tell) -
>>> >>
>>> >> but didn't we discuss this and agree in a meeting last week? I do
>>> >> remember checking it ...because I was not sure ...
>>> >>
>>> >> I said something about it being a repeatable property but we had to
>>> >> know that we could stop the sets being concatenated and Charles N
>>> >> said that could be done with a 'blank node' .... and this was in
>>> >> email too...
>>> >>
>>> >> Liddy
>>> >>
>>> >> On 07/11/2013, at 2:32 PM, Madeleine Rothberg wrote:
>>> >>
>>> >>> The group has not agreed to the changes in the definition of
>>> >>> access mode
>>> >>> included here.
>>> >>>
>>> >>> -Madeleine
>>> >>>
>>> >>> On 11/6/13 10:16 PM, "Liddy Nevile" <liddy@sunriseresearch.org>
>>> >>> wrote:
>>> >>>
>>> >>>> Dan,
>>> >>>>
>>> >>>> your write-up is slightly outdated because we have decided that
>>> >>>> accessFeature is a better name for the property than
>>> >>>> mediaFeature...this aligns better with accessMode, we think...
>>> >>>> and we
>>> >>>> have also accessHazard and accessControl, I think.
>>> >>>>
>>> >>>> We have refinements of these, and for some we have controlled 
>>> vocab
>>> >>>> values - but I am assuming that these are not what you need now???
>>> >>>> (below I have given the write-up a go...)
>>> >>>>
>>> >>>> Liddy
>>> >>>>
>>> >>>> On 07/11/2013, at 3:46 AM, Dan Brickley wrote:
>>> >>>>
>>> >>>>>
>>> >>>>> Sounds like you've been very busy! Will someone who is following
>>> >>>>> this
>>> >>>>> closely be in a position to produce an updated version of the
>>> >>>>> draft
>>> >>>>> RDFS configuration file we'll need for schema.org? If not, let
>>> >>>>> me know
>>> >>>>> if you need help (presumably once the revised spec is out). The
>>> >>>>> current version I've drafted is at
>>> >>>>>
>>> >>>>> 
>>> https://dvcs.w3.org/hg/webschema/file/default/schema.org/ext/accessibilit
>>> >>>>> y.html
>>> >>>>>
>>> >>>>> Dan
>>> >>>>
>>> >>>> 1 <html>
>>> >>>> 2 <head>
>>> >>>> 3 <title>Accessibility vocab</title>
>>> >>>> 4 </head>
>>> >>>> 5 <body>
>>> >>>> 6
>>> >>>> 7 <div>
>>> >>>> 8 <h1>Accessibility Vocabulary</h1>
>>> >>>> 9 <p>See <a href="http://www.w3.org/wiki/WebSchemas/
>>> >>>> Accessibility">wiki</a> and <a href="http://
>>> >>>> a11ymetadata.org/">a11ymetadata.org</a> for details.</p>
>>> >>>>
>>> >>>> 10 <div typeof="rdf:Property" 
>>> resource="http://schema.org/accessHazard
>>> >>>> ">
>>> >>>> 11 <span property="rdfs:label">accessHazard</span>
>>> >>>> 12 <span property="rdfs:comment">A characteristic of the described
>>> >>>> resource that is physiologically dangerous to some users.</span>
>>> >>>> 13 <span>Domain: <a href="http://schema.org/CreativeWork"
>>> >>>> property="schema:domain">CreativeWork</a></span>
>>> >>>> 14 <span>Range: <a href="http://schema.org/Text"
>>> >>>> property="schema:range">Text</a></span>
>>> >>>> 15 </div>
>>> >>>>
>>> >>>> 16 <div typeof="rdf:Property" resource="http://schema.org/
>>> >>>> accessFeature">
>>> >>>> 17 <span property="rdfs:label">accessFeature</span>
>>> >>>> 18 <span property="rdfs:comment">Access features of the resource
>>> >>>> commonly used as accessible alternatives, such as signLanguage
>>> >>>> (used
>>> >>>> in visual assessMode).</span>
>>> >>>> 19 <span>Domain: <a href="http://schema.org/CreativeWork"
>>> >>>> property="schema:domain">CreativeWork</a></span>
>>> >>>> 20 <span>Range: <a href="http://schema.org/Text"
>>> >>>> property="schema:range">Text</a></span>
>>> >>>> 21 </div>
>>> >>>>
>>> >>>> 16 <div typeof="rdf:Property" 
>>> resource="http://schema.org/accessMode
>>> >>>> ">
>>> >>>> 17 <span property="rdfs:label">accessMode</span>
>>> >>>> 18 <span property="rdfs:comment">A set of sensory modalities
>>> >>>> through
>>> >>>> which all the intellectual content of a described
>>> >>>> resource or component is communicated, such as visual + auditory;
>>> >>>> text; etc. </span>
>>> >>>> 19 <span>Domain: <a href="http://schema.org/CreativeWork"
>>> >>>> property="schema:domain">CreativeWork</a></span>
>>> >>>> 20 <span>Range: <a href="http://schema.org/Text"
>>> >>>> property="schema:range">Text</a></span>
>>> >>>> 21 </div>
>>> >>>>
>>> >>>> 16 <div typeof="rdf:Property" resource="http://schema.org/
>>> >>>> accessControl">
>>> >>>> 17 <span property="rdfs:label">accessControl</span>
>>> >>>> 18 <span property="rdfs:comment">Content features of the resource,
>>> >>>> such as fully controllable using only keyboard.</span>
>>> >>>> 19 <span>Domain: <a href="http://schema.org/CreativeWork"
>>> >>>> property="schema:domain">CreativeWork</a></span>
>>> >>>> 20 <span>Range: <a href="http://schema.org/Text"
>>> >>>> property="schema:range">Text</a></span>
>>> >>>> 21 </div>
>>> >>>> 22 </div>
>>> >>>> 23
>>> >>>> 24 </body></html>
>>> >>>>
>>> >>>> --
>>> >>>> You received this message because you are subscribed to the
>>> >>>> Google Groups
>>> >>>> "Accessibility Metadata Project" group.
>>> >>>> To unsubscribe from this group and stop receiving emails from it,
>>> >>>> send an
>>> >>>> email to a11y-metadata-project+unsubscribe@googlegroups.com.
>>> >>>> To post to this group, send email to
>>> >>>> a11y-metadata-project@googlegroups.com.
>>> >>>> For more options, visit https://groups.google.com/groups/opt_out.
>>> >>
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Accessibility Metadata Project" group.
>>> > To unsubscribe from this group and stop receiving emails from it,
>>> > send an email to a11y-metadata-project+unsubscribe@googlegroups.com.
>>> > To post to this group, send email to 
>>> a11y-metadata-project@googlegroups.com
>>> > .
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>
>

Received on Thursday, 7 November 2013 22:22:27 UTC