W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2013

Re: is/hasAdaption

From: Liddy Nevile <liddy@sunriseresearch.org>
Date: Fri, 4 Oct 2013 10:39:32 +1000
Cc: "<public-vocabs@w3.org>" <public-vocabs@w3.org>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>
Message-Id: <26A2D036-A09E-4DC2-BD89-F6BADDA81C1A@sunriseresearch.org>
To: Madeleine Rothberg <madeleine_rothberg@wgbh.org>


I am not saying that we cannot point to other resources/components). I  
think that we agreed that there are metadata schema that describe the  
relationship between resources and point from one to another. I am  
saying that where you want to point or relate resources, that metadata  
(already part of schema.org, eg.), should be used.

I am not sure of what I see as the other part of what you are saying:

Suppose I have a resource that has a number of redundant components so  
that it will be available to a user in a range of forms, and those  
bits and pieces have different locations. This is very likely to be  
the case where a new alternative is added. In the original resource,  
there can easily be a pointer to the alternative and I expect HTML 5  
to cater for that - is this the case, Charles (N)???.

Otherwise, I assume that if the alternative is covered by metadata it  
will be identified as  an alternative and used?

I am not sure I see the problem.....


On 04/10/2013, at 12:31 AM, Madeleine Rothberg wrote:

> (Adding the a11y list, in case there is anyone on that list who is not
> also on public vocabs.)
> Liddy,
> Saying that we want to calculate the set of access modes that can  
> provide
> full access to a resource does not take away the need to locate the
> supplementary resources that make those sets possible. If the  
> transcript
> for an audio file is in a different location than the audio file,  
> one way
> to find it would be to have a direct indication in the metadata that  
> it is
> the transcript for that audio file over there (and/or vice versa, if  
> the
> audio file's metadata author is aware of the transcript). Perhaps  
> really
> good search engines can figure that out from other metadata on the two
> resources, but the search will be easier if the explicit link is  
> provided.
> People who are purposely creating access features and adding a11y  
> metadata
> to them will be motivated to provide that link.
> We also imagine cases where a search engine will turn up useful
> equivalents that were never intended to provide an access feature to a
> particular inaccessible resource, but have enough metadata to be
> identified as such. And that's great, but it doesn't take away the  
> value
> of encoding those relationships when we do know them.
> -Madeleine
> On 10/3/13 3:51 AM, "Liddy Nevile" <liddy@sunriseresearch.org> wrote:
>> Madeleine,
>> as I understand it - there is not much point in having to specify the
>> is/has adaptation - there will be multiple format combinations
>> available and I think we infer from the choice of a user for captions
>> that they do not need audio (might get it but need text alternative
>> (captions) whenever there is audio).
>> As we have abandoned the idea of 'original version' of a resource
>> (except for where this is identified using appropriate, other  
>> metadata
>> based on FRBR or the equivalent), it is not necessary to specify all
>> the alternatives as such - instead I thought we'd agreed to specify
>> the set of accessMedia that would give complete access to the
>> resource. Is that not right ???
>> Liddy
>> On 03/10/2013, at 1:48 PM, Madeleine Rothberg wrote:
>>> Liddy,
>>> In what discussion was is/hasAdaptation discredited? I am not aware
>>> of that change in direction.
>>> Madeleine
>>> On 2013-10-02, at 10:16 PM, "Liddy Nevile"
>>> <liddy@sunriseresearch.org> wrote:
>>>> Richard,
>>>> I think it is no longer necessarily the case that we will be using
>>>> hasAdaptation etc any more - that belongs to a model that I think
>>>> is discredited now...
>>>> Liddy
>>>> On 02/10/2013, at 11:24 PM, Wallis,Richard wrote:
>>>>> It is great to see the progress on the accessibility front.  I am
>>>>> supportive of most of the proposals.
>>>>> I would have liked to participate in the call(s) next week but can
>>>>> not, due to travel/speaking commitments.  There is an issue that I
>>>>> would have raised if I could attend.
>>>>> The term adaption has specific meaning in the accessibility
>>>>> context where the properties hasAdaption & isAdaptionOf make
>>>>> sense.  However in the academic & bibliographic domains adaption
>>>>> has an established and different meaning.  Those property names
>>>>> would also make sense to a librarian, but for different reasons.
>>>>> On the one hand we are describing, as an adaption, something with
>>>>> essentially the same content that has been adapted for
>>>>> accessibility reasons; on the other we are describing something
>>>>> which has had its content adapted to provide a different
>>>>> [literary] view.
>>>>> Librarians 'know' what they mean by adaption, as will
>>>>> accessibility oriented professionals will know what is meant in
>>>>> their domain.  However going for an undifferentiated property
>>>>> name, such as hasAdaption, will lead to ambiguity and confusion
>>>>> further down the line with accessibility/bibliographic oriented
>>>>> softwares having no certainty as to what type of adaption is being
>>>>> referenced.
>>>>> Checking out the wikipedia disambiguation page for adaption,
>>>>> highlights that this could be a problem for more that just two
>>>>> communities.
>>>>> In an earlier accessibility threads, Karen Coyle suggested the use
>>>>> of 'hasAdaptionForAccess' & 'isAdaptionForAccessOf' I have a
>>>>> preference for the slightly shorter 'hasAccessibilityAdaption' &
>>>>> 'isAccessibilityAdaptionOf'.
>>>>> Of course this then raises the question of what property names we
>>>>> would use for the bibliographic domain - something to go on the
>>>>> agenda of the next SchemaBibEx Group meeting methinks!
>>>>> ~Richard
Received on Friday, 4 October 2013 00:41:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:32 UTC