additional value for unrestricted access to resources

5 views
Skip to first unread message

Matt Garrish

unread,
Dec 17, 2013, 11:51:38 AM12/17/13
to a11y-metad...@googlegroups.com

Comparing our metadata against ONIX, and also looking at ebook production, one feature we’re missing is the ability to say that access to a resource has not been restricted in any way (e.g., through digital rights management).

 

Consequently, I’d like to additionally propose we include the value unrestrictedAccess for accessibilityFeature. This value would indicate that restriction measures have not been applied to the resource, and would be the equivalent of value 10 in the code list.

 

As there haven’t been any objections to the proposed changes, I’m going to begin updating the various sites to reflect them today. If there are any change requests in the future, it’ll be easier to deal with them having the new value set in place.

 

Matt

Anastasia Cheetham

unread,
Dec 17, 2013, 12:12:08 PM12/17/13
to Matt Garrish, a11y-metad...@googlegroups.com
On 2013-12-17, at 11:51 AM, Matt Garrish wrote:

Comparing our metadata against ONIX, and also looking at ebook production, one feature we’re missing is the ability to say that access to a resource has not been restricted in any way (e.g., through digital rights management).
 
Consequently, I’d like to additionally propose we include the value unrestrictedAccess for accessibilityFeature. This value would indicate that restriction measures have not been applied to the resource, and would be the equivalent of value 10 in the code list.

I don't believe that rights management should be considered an accessibility feature. Aren't there other properties for that?

-- 
Anastasia Cheetham                    a...@anastasiacheetham.ca
Inclusive Design Research Centre              OCAD University

Daniel, Ronald (ELS-SDG)

unread,
Dec 17, 2013, 12:23:04 PM12/17/13
to Anastasia Cheetham, Matt Garrish, a11y-metad...@googlegroups.com

I agree with Anastasia. For one thing, rights can change over time. Avoid the quagmire of rights.

 

Ron Daniel

Elsevier Labs

--
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-pr...@googlegroups.com.
To post to this group, send email to a11y-metad...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Linda Turner

unread,
Dec 17, 2013, 12:26:08 PM12/17/13
to a11y-metad...@googlegroups.com

I don’t think Matt is talking about the rights themselves, but what DRM features are used to protect the document. It is related by the fact that certain DRM features can restrict the accessibility of a resource. It used to be the case that if PDF’s were completely locked down, or included watermarks, then screen readers could not read the document correctly. While PDF accessibility has improved, somewhat, users could find it helpful to know what DRM features have been used.

 

thanks, Linda

 

Linda Turner

Technical Services & Digital Resources Mgr.

American Printing House f/t Blind  1839 Frankfort Ave.  Louisville, KY 40206  (800-223-1839 x342  http://louis.aph.org/

 

From: a11y-metad...@googlegroups.com [mailto:a11y-metad...@googlegroups.com] On Behalf Of Anastasia Cheetham
Sent: Tuesday, December 17, 2013 12:12 PM
To: Matt Garrish
Cc: a11y-metad...@googlegroups.com
Subject: Re: [a11y-metadata-project] additional value for unrestricted access to resources

 

 

On 2013-12-17, at 11:51 AM, Matt Garrish wrote:

--

Madeleine Rothberg

unread,
Dec 17, 2013, 12:30:15 PM12/17/13
to a11y-metad...@googlegroups.com
I agree that there are ways in which DRM directly effects accessibility, but I suggest we look at other projects in Schema.org to see if there are properties that already cover this area. We can't do it justice, and if there is better information already recorded, we could confuse people by adding a simple property about DRM. It might turn out that we can suggest a new value or two for an existing property, and then include it in our best practices.

-M

Matt Garrish

unread,
Dec 17, 2013, 12:46:20 PM12/17/13
to Madeleine Rothberg, a11y-metad...@googlegroups.com

That’s the problem; there really isn’t any ability to handle rights management restrictions of any kind. I don’t think the schema.org folks want to open that particular can of worms (the LRMI group had tried to add useRightsUrl with no luck), and I’m not suggesting we go the route of trying to elaborate on what usage rights you have to a resource. I was only thinking about how we can record both that access is not restricted and that access is not restricted in such a way that it impacts on the ability of AT to interact with the content.

 

It would be nice to know, given two DAISY books, which is protected and which not, but if no one wants to go in that direction, that’s okay. It would still be useful to have a marker that indicates that access to the resource has not been restricted in a way that is detrimental to AT access, I believe.

 

Matt

 


Madeleine Rothberg

unread,
Dec 17, 2013, 1:59:10 PM12/17/13
to a11y-metad...@googlegroups.com
I see the problem! In that case, something simple might work, based on DAP perhaps?

-Madeleine

matt.g...@bell.net

unread,
Dec 17, 2013, 3:59:28 PM12/17/13
to Madeleine Rothberg, <a11y-metadata-project@googlegroups.com>
DAP uses a text field called "security" to express restrictions or that there is no DRM (see [1] for example). Onix code list 196 value 10 is a boolean that indicates that functionality has not been restricted, whether by the application of DRM or otherwise, but the value does not necessarily mean DRM-free.
 
I don't think we could have a single value that expresses both conditions, given the distinction between the application of DRM and whether it impacts the accessibility. Compatibility with AT seems like a feature that could have been expressed in ATCompatible. Maybe we could leave the discussion of a lack of impact on AT access to discussions about the future of ATCompatible in v. 1.1?
 
In that light, would it make sense to include a less rights loaded value like "unlocked" only to address that DRM has not been applied?
 
[1] http://stepp.gatech.edu/label-view.php?id=62
 
Matt
 

To: a11y-metad...@googlegroups.com
Subject: Re: [a11y-metadata-project] additional value for unrestricted access to resources
Date: Tue, 17 Dec 2013 18:59:10 +0000

Treviranus, Jutta (Academic)

unread,
Dec 17, 2013, 5:21:51 PM12/17/13
to <matt.garrish@bell.net>, Madeleine Rothberg, <a11y-metadata-project@googlegroups.com>
Given that accessibility is often achieved by adapting the presentation or means of controlling a resource by someone that is not the author or rights owner, DRM, which impedes this process, is definitely highly germane to accessibility.

I agree, a flag that indicates that a resource is 'open' or 'unlocked' would be very useful without getting into the specifics of the type of DRM used.

Jutta

Jutta Treviranus
Professor and Director
Inclusive Design Research Centre and Inclusive Design Institute
OCAD University

On 2013-12-17, at 3:59 PM, <matt.g...@bell.net>
wrote:

> DAP uses a text field called "security" to express restrictions or that there is no DRM (see [1] for example). Onix code list 196 value 10 is a boolean that indicates that functionality has not been restricted, whether by the application of DRM or otherwise, but the value does not necessarily mean DRM-free.
>
> I don't think we could have a single value that expresses both conditions, given the distinction between the application of DRM and whether it impacts the accessibility. Compatibility with AT seems like a feature that could have been expressed in ATCompatible. Maybe we could leave the discussion of a lack of impact on AT access to discussions about the future of ATCompatible in v. 1.1?
>
> In that light, would it make sense to include a less rights loaded value like "unlocked" only to address that DRM has not been applied?
>
> [1] http://stepp.gatech.edu/label-view.php?id=62
>
> Matt
>
> From: madeleine...@wgbh.org
> To: a11y-metad...@googlegroups.com
> Subject: Re: [a11y-metadata-project] additional value for unrestricted access to resources
> Date: Tue, 17 Dec 2013 18:59:10 +0000
>
> I see the problem! In that case, something simple might work, based on DAP perhaps?
>
> -Madeleine
>
> From: Matt Garrish <matt.g...@bell.net>
> Date: Tuesday, December 17, 2013 12:46 PM
> To: Madeleine Rothberg <madeleine...@wgbh.org>, "a11y-metad...@googlegroups.com" <a11y-metad...@googlegroups.com>
> Subject: RE: [a11y-metadata-project] additional value for unrestricted access to resources
>
> That’s the problem; there really isn’t any ability to handle rights management restrictions of any kind. I don’t think the schema.org folks want to open that particular can of worms (the LRMI group had tried to add useRightsUrl with no luck), and I’m not suggesting we go the route of trying to elaborate on what usage rights you have to a resource. I was only thinking about how we can record both that access is not restricted and that access is not restricted in such a way that it impacts on the ability of AT to interact with the content.
>
> It would be nice to know, given two DAISY books, which is protected and which not, but if no one wants to go in that direction, that’s okay. It would still be useful to have a marker that indicates that access to the resource has not been restricted in a way that is detrimental to AT access, I believe.
>
> Matt
>
> To unsubscribe from this group and stop receiving emails from it, send an email toa11y-metadata-p...@googlegroups.com.

Liddy Nevile

unread,
Jan 16, 2014, 6:45:54 PM1/16/14
to Treviranus, Jutta (Academic), <matt.garrish@bell.net>, Madeleine Rothberg, <a11y-metadata-project@googlegroups.com>
I think this is a pretty tricky area - saying something is 'open' or
'unlocked' does not convey enough - esp as it is confusing to know if
it is about IP or about code etc - I think the best that we could do
is point to rights owners - or CC statements etc - not trying to
define yet another term. We have been doing a lot of work on this in
the ISO context ...

Liddy
>> 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 toa11y-metadata-p...@googlegroups.com.
>> To post to this group, send email to a11y-metad...@googlegroups.com
>> .

Madeleine Rothberg

unread,
Jan 17, 2014, 4:43:02 PM1/17/14
to Liddy Nevile, Treviranus, Jutta (Academic), <matt.garrish@bell.net>, <a11y-metadata-project@googlegroups.com>
A recent comment on the public vocabs list suggests that schema.org will
not accept any property that refers to DRM.

Quote from Dan Scott:
My understanding is that schema.org refuses to include license
properties, which I believe trying to annotate levels of Open Access
would fall under.


So I don't think we will have any success with this, no matter how simple
we think our proposal is.

-Madeleine

Steve Midgley

unread,
Jan 17, 2014, 5:18:57 PM1/17/14
to Madeleine Rothberg, Liddy Nevile, Treviranus, Jutta (Academic), <matt.garrish@bell.net>, <a11y-metadata-project@googlegroups.com>
What about DRM "type" rather than license info?

DRMType: [none|adobe3|xyz-type]

It's just a plain text string with some recommend values and "none" as one of the options. This is to indicate what type of DRM strategy is used, and not to refer to the license disposition at all? You can certainly release a DRM free ebook or mp3 that has a restrictive copyright license.. I think others are proposing a similar idea but wanted to clarify one approach.

Steve

Matt Garrish

unread,
Jan 17, 2014, 6:02:56 PM1/17/14
to Madeleine Rothberg, Liddy Nevile, Treviranus, Jutta (Academic), a11y-metad...@googlegroups.com
It's only a suggested value for accessibilityFeature. I don't want to get
into the complexity of defining a property, either.

What values are used with a property is fluid, so I was posing it more as a
question of whether we include it in our recommended list or whether we
leave it to be developed for domain-specific uses. It leaves a hole for
ebooks if we can't convey the information.

Matt
Reply all
Reply to author
Forward
0 new messages