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

Thanks for doing this content for Dan, Liddy.  It'd be great if you took 
on the other ones as well, especially accessAPI and the others.  We 
ought to have one RDFS source that reflects our current complete 
thought...  we can edit this as properties make it or not.  But I am 
truly grateful for this, as it was an editing task that I was looking at 
taking on myself.  Anything that goes off my list is goodness.

As editor of the specification, I'd like to say a few things:

 1. The  draft of the specification is at
    http://www.w3.org/wiki/WebSchemas/Accessibility (I'm proofreading it
    at the moment, but I have updated all the names, and added a section
    that explains accessFeature in more depth.  This is my first attempt
    at explaining the accessFeatures in a more cogent but still terse
    fashion.  Send me comments (or, better yet, editted text) and I'd be
    glad to have impromptu group calls if they are needed.
 2. There seem to be multiple opinions on access mode, which are
     1. It's the access mode of the non-augmented content (the
        traditional AfA method, and what we believe is called for in in
        epub3)
     2. It's the set of access modes of the augmented content (what
        search engines would like to work from)
     3. That we might want to specify which search engine access modes
        are NOT needed in the augmented content (this was a discussion
        off the list and did not pass muster from the off-the-list group
        to bring it forward)
     4. That accessMode is a third rail.  Whether it causes
        electrocution or derailment is unclear, but neither of these are
        ends to aspire to.
 3. I believe that the path on access mode is to keep it in here (the
    augmentation access features only make sense in that context, as
    well as the extensions for the access mode refinements)
 4. Once we have agreement on 1-4 on the list below, we can tackle 5 and
    6. But, as I've said on the calls before, we have to pin down one of
    these (accessFeature) before the other two (accessMode and is/has
    adaptation) can proceed.

We may not get all of these properties adopted into schema.org at once, 
although I would love to see that happen. There is still a concrete 
order for properties and their adoption that we're going for, which was 
set by Charles and I in calls back in early October and have been posted 
in the agenda since early October.


 1. AccessHazard (done)
 2. mediaFeature (now accessFeature) (done as far as we're concerned,
    but there is no confirmation of that from Charles McN and schema.org)
 3. ATCompatible
 4. accessControl (was controlFlexibility) and accessAPI
 5. accessMode and the three proposals for the available access modes
 6. is/hasAdaptation

Let's keep with that original order, or have a discussion on the order 
rather than changing the meaning of a property (my personal opinion is 
that use cases will reveal that both the source and augmented access 
modes are needed and that we need a way to represent them as unique 
concepts... see the issue tracker for detail on the proposals).

And we need to agree to one specification, and to have the RDFS describe 
that specification. We'll get into serious trouble if we diverge from a 
methodical process.

So, review the specification (I think I will bring over a definition of 
accessMode from the best practices guide) and let's make concrete use 
cases and proposals for the "other type of access mode desired."

On 11/7/2013 12:58 AM, Liddy Nevile wrote:
> Andy,
>
> as I have not made a new property, I am not sure what you are agreeing 
> with - I also agree that there should not be a new one???? Did you 
> manage to look at what I have worked on?
>
> Liddy
>
>
> On 07/11/2013, at 6:00 PM, Andy Heath wrote:
>
>> I agree with Madeleine and Matt.  I can't type long arguments on this 
>> but they have been made many times and at this point are probably in 
>> my view a distraction of focus. There is certainly in my opinion a 
>> majority of the IMS AfA 3 contributors/editors in favour of 
>> maintaining the status quo on AccessMode, and knowing the views that 
>> Jutta has expressed I believe there is a majority of 24751 editors 
>> also. I propose we close the issue on changing AccessMode. That does 
>> not prevent discussion of additional fields for computed values or 
>> author-intended-uses at this or any later point.
>>
>> Andy
>>
>> Sent from my iPad
>>
>>> On 7 Nov 2013, at 05:01, Matt Garrish <matt.garrish@bell.net> 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.
>>> -- 
>>> 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.
>