Re: [a11y-metadata-project] Re: is/hasAdaption

> and I think we would do better to wait on the exampleOfWork

I'd agree to this approach over using the existing properties. I'd initially 
read it as grouping manifestations of a single work, but spotted this 
sentence rereading:

> allowing for any schema:CreativeWork description to reference other 
> CreativeWorks that it is an example/instance of

There is also a need to know which specific manifestation is being adapted, 
not just that there is a collection of related manifestations to which the 
current belongs. The obvious case being pagination in an ebook, braille or 
large print book. Bookshare, for example, probably doesn't want to just tell 
its clients that here is a manifestation of an overarching work, but here is 
a representation of this specific manifestation containing its pagination 
markers.

If the "work" can be a "manifestation" in this model, as appears above, all 
the good.

The ultimate usability will hinge on commonality of identification. Provided 
something easy like an ISBN for the user to search on, alternatives could be 
found, but if the reference is a fragment identifier within a page probably 
not so much. But then the existing property has that limitation.

Matt

-----Original Message----- 
From: Charles McCathie Nevile
Sent: Friday, October 04, 2013 1:42 PM
To: Madeleine Rothberg ; public-vocabs@w3.org ; 
a11y-metadata-project@googlegroups.com ; Wallis,Richard ; Matt Garrish
Subject: Re: [a11y-metadata-project] Re: is/hasAdaption

On Fri, 04 Oct 2013 12:52:28 +0100, Matt Garrish <matt.garrish@bell.net>
wrote:

>> Right now there is isBasedOn
>
> It's description doesn't seem to suggest such a good fit, though: A 
> resource that was used in the creation of this resource. I thought this 
> property was introduced by LRMI to identify resources that were pulled 
> into making a new resource (e.g., open textbooks).

That's its provenance I believe.

> I'd be hesitant to lift the name and ascribing a new interpretation to
> it, which is why I noted below it's best to stay away from the
> minefield of metadata that has other applications.

There is a tension between using highly detailed metadata and uing rough
and ready stuff that is more intuitive and doesn't need a training manual
to understand.

In my personal opinion schema.org has tended towards the pragmatic and
somewhat loose over the highly specialised ontology, and that is teh way
it should continue to lean.

I believe the bibex group also have the same expectation.

But I could certainly be wrong on both counts...

>> and sameAs
>
> I'm not sure this applies, either: URL of a reference Web page that 
> unambiguously indicates the item's identity. At least based on my often 
> meagre understanding of owl, this property is focused on establishing a 
> shared identity (e.g., variations in name), not pointing that one 
> resource is equivalent but differently adapted to another (and not for 
> parts of a whole).

Well, it has a pretty loose notion of identity. A football club, a book,
an individual person, are the sort of things described in WikiPedia, which
is used as an example of the kind of "identity definition" expected.

I'm wary of this property for other reasons - and I think we would do
better to wait on the exampleOfWork (and workExample) properties of bibex
mentioned in my previous mail. But if I need to do something faster, I
think this approach is reasonable.

> I'm certainly not wedded to any one approach, but I'd like to make sure 
> that there is at least one unambiguous way to express this relationship 
> before we drop it as unnecessary. The people who think about these  things 
> haven't suggested that our use case already has a functional  equivalent, 
> only that its name collides with another meaning, so I'm  still inclined 
> to think there is value in what we're trying to establish  with these 
> properties.
>
> But, right, my follow up question if the reference was abroad was  whether 
> we were willing to limit the metadata to RDFa implementations.  Glad to 
> hear the discussion hasn't moved that far.
>
> As far as bidirectionality of linking goes, I'm not wedded to any one 
> approach. For republishing of ebooks, there's typically only one 
> direction, after all.

Typically - although that is changing. Inter alia, most authors produce an
eBook of some kind as the native form before pubilshing it. And that has
been a clear trend since the early 80s. Multimedia works are very often
born digital, and often multi-faceted, permitting several "adaptations" as
a fundamental feature of the medium.

> But if a relationship can go one way, it can go back the other (rel/rev, 
> among many other bidirectional relationship mechanisms springs to mind).

Yes.

cheers

Chaals

> Matt
>
> -----Original Message----- From: Charles McCathie Nevile
> Sent: Friday, October 04, 2013 9:50 AM
> To: Madeleine Rothberg ; public-vocabs@w3.org ; 
> a11y-metadata-project@googlegroups.com ; Matt Garrish ; Wallis,Richard
> Subject: [a11y-metadata-project] Re: is/hasAdaption
>
> On Fri, 04 Oct 2013 04:51:30 +0100, Matt Garrish <matt.garrish@bell.net>
> wrote:
>
>> What property from schema.org are you proposing replaces these, Liddy?
>
> Right now there is isBasedOn which applies to CreativeWork and sameAs
> which applies to any Thing, including CreativeWork.
>
> The former is like "isAdaptation", but generic, so the resource might 
> have
> accessibility metadata - or there might be third-party accessibility
> metadata available for the resource.
>
> sameAs is a bit trickier. It identifies "things that are the same" but is
> unclear whether that means "Alice in Wonderland" the eBook is the sameAs
> the annotated "Alice in Wonderland" (2nd edition) from OUP in 1993.
>
>> I understand the hesitation about using a name like "adaptation", given 
>> the broad nature of schema.org, but we aren't moving off into the realm 
>> of telling people they have to incorporate external vocabularies, are 
>> we?
>
> No, we need to use properties that are in schema.org (inter alia, because
> microdata is too limited to do anything else).
>
> We *expect* schema.org to adopt stuff from the bibex group, which is
> proposing
> http://www.w3.org/community/schemabibex/wiki/CreativeWork_Relationships 
> to
> handle this. Note that librarians have spent years thinking about this
> question, and their assumptions include things that other people don't
> consider (so may not understand easily). But their development is driven
> by use cases, including ones similar to ours (find a version of this
> CreativeWork that works on my device).
>
>> I would note that by having a property at the simpler level of 
>> indicating that one has a relation to the other in terms of differing 
>> access modes, media features, etc. (which is more directly what our 
>> proposal is about) we avoid the potential stickiness of delving into  the 
>> nature of the relationship of the content itself (which many 
>> relationship properties are concerned with).
>
> Indeed.
>
> cheers
>
> Chaals
>
>> Matt
>>
>> -----Original Message----- From: Madeleine Rothberg
>> Sent: Thursday, October 03, 2013 9:28 PM
>> To: <public-vocabs@w3.org> ; a11y-metadata-project@googlegroups.com
>> Subject: Re: is/hasAdaption
>>
>> Ah, OK. You are saying that generic "is related to" metadata can be 
>> used,
>> and that we don't need accessibility-specific versions of those
>> relationships.
>>
>> I guess I would leave this to the search engines participants to weigh 
>> in
>> on -- does it improve search to know more specifically that this is an
>> accessibility adaptation of that, or is it fine to know they are 
>> related,
>> and then go dig through other metadata to figure out the relationship? 
>> To
>> be fair, a "has adaptation" link may not say much about what kind of
>> adaptation is at the end of the link. But "is adaptation" metadata is
>> probably accompanied by some details about what kind of adaptation this 
>> is.
>>
>> -Madeleine
>>
>> On 10/3/13 8:39 PM, "Liddy Nevile" <liddy@sunriseresearch.org> wrote:
>>
>>> mmm...
>>>
>>> Madeleine
>>>
>>> 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.....
>>>
>>> Liddy
>>>
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

-- 
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 Friday, 4 October 2013 16:52:27 UTC