Selected postings, Feb 17 to Mar 23 discussion of Accessibility ------------------------------------------------------------------------ Date: Thu, 17 Feb 2005 08:10:47 +0000 From: Pete Johnston http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0502&L=dc-usage&T=0&O=A&P=4035 ------------------------------------------------------------------------ Quoting Andy Powell : > Well, I guess I am guilty of having missed the subtle point about matching > two sets of metadata - though I think this needs to be brought out in the > comment rather than in the definition. Not sure these thoughts are helpful at this point! ;-) First, I also had some doubts about the name of the property. I had grasped this aspect of a process matching resource description and user description, and for this very reason I always wondered about whether "accessibility" was the right name for a property of a resource ;-) Because (according to this very principle of accessibility being the result of a process), a statement made using the accessibility property doesn't actually describe the "accessibility" of the resource, if you see what I mean! It just provides a basis for a process to take place (involving a description of the resource and a description of the user), the outcome of which is an indication of the accessibility of that resource for that user. Secondly, I must admit I was struggling to grasp the underlying model here. I did have a couple of exchanges with Liddy and one of her colleagues before Shanghai, but they weren't able to provide any examples of how this was implemented in RDF (and I got too busy and didn't pursue it). It seems to me that as proposed the accessibility property describes a relation between a resource and a _description_ of that resource - where that description describes those specific attributes of the resource that support the "accessibility assessment" process). The information that is represented in this "accessibility-related attributes description" is a set of statements about the resource - the same resource as in the first description - and in an RDF implementation there would be a set of properties to represent this (about use of colour, use of audio etc. It seems to me in this model you would never actually need an "accessibility" property at all! If this set of statements was stored as a separate physical RDF/XML doc from the resource discovery description, then you'd just use rdfs:seeAlso to indicate there was more stuff about the subject resource. But the only descriptions I can find of how the "accessibility-related attributes description" is represented refer to XML - document-based, rather than statement-based, specifically http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_infov1p0.html so it doesn't really help disentangle this. Having said all this, I'm conscious that the dc:rights property takes a very similar approach to that suggested for the accessibility property - I think effectively often a dc:rights property points to another "description" (which has statements about the same resource covering those attributes of the resource that are concerned with rights) - so there is a precedent. OTOH, I think this aspect of dc:rights has caused us a few headaches as well, and I'm not sure that if we were starting again we'd take the same approach. Oh dear. Not sure that was constructive at this point in the proceedings! ------------------------------------------------------------------------ Date: Thu, 17 Feb 2005 18:49:37 -0000 From: Pete Johnston http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0502&L=dc-usage&T=0&O=A&P=3829 ------------------------------------------------------------------------ Hi Stuart, > Pete, I believe that your description of how some see the > property used and and your comparison with rights is correct. OK, thanks. > However, as comments from others on the UB indicate (see > Diane's previous post) indicate, that is not the _only_ way > the property may be used and, in fact, any hint of of that > specific use was moved from the definition to the comment (as > best practice) in order to generalize the semantics of the > property. So, just as rights may contain a string value made > up of a rights statement, but can also reference an separate > rights description, so may the accessibility property. OK. > I'd like to hear more regarding your statement: "I think this > aspect of dc:rights has caused us a few headaches as well, > and I'm not sure that if we were starting again we'd take the > same approach." I think my concern touches on your comment here. dc:rights and the proposed property (maybe dc:description too) adopt a slightly different modelling "style" from the other properties. What I mean by that is I think most of the other properties are deployed to describe a relationship between the subject resource and another thing resource-R is-created-by person-P resource-R has-as-topic concept-C and so on. OK, so does dc:rights, and the other thing is a "rights statement". OK, but suppose I have a description which includes: resource-R has-rights-statement statement-S Now, in the case of dc:rights that other thing is, or a least may be, or may include, a description of, resource-R! i.e. statement S might be an RDF/XML document containing the statement resource-R is-available-under-license license-L So, hang on a minute... why didn't we just say that (using dcterms:license)? What is the difference between the two approaches? And why do we say resource-R has-rights-statement statement-S rather than resource-R see-Also statement-S (using rdfs:seeAlso, which is how you would usually say "more data about this over here"). As you point out, I think the reason is that we are trying to allow for both unstructured plain literal "rights statements" and resources as rights-statements. I think this really goes back to the more general value-as-resource v value-as-literal debate. Most RDF vocabularies (I think) don't allow this choice. Properties which can have literal values are defined to always have literal values; properties that have other resources as values don't take literals as values. Now in the Abstract Model, we've said values are always resources and although we haven't worked out how this is going to be implemented in RDF, I'm guessing we'll say the dc:rights RDF property never has a plain literal value, but it could have some intermediate node with a literal value hanging off it. I'm not sure that really solves the problem but I haven't thought that bit through.... I dunno... maybe it's all a non-problem, but the fact that it leads to some slightly odd questions leaves me with niggling doubts about whether the underlying approach is quite right. But I appreciate that is a very vague specification of the problem! ;-) I was/am really curious to see how the Accessibility people address this in RDF partly because, well, I just want to know (!), and partly because I think if they have worked through some of these issues it would provide some very useful models to guide us. (Andy and I had a brief chat about this earlier and he commented that similar issues will arise in the ODRL-DC work that is in progress.) But most of the references I find are to EARL, and all that material seems to be dated 2001 and I'm not clear what its status is. And while I think I understand broadly what EARL does, I'm rather less clear about how it integrates with e.g. a DC metadata description. From my fairly hasty reading of it, I'm not really sure I see a need for a dcterms:accessibility property to reference an EARL statement, just for rdfs:seeAlso to say "there's some more RDF data over here". ------------------------------------------------------------------------ Date: Thu, 31 Mar 2005 11:14:26 +0100 From: Andy Powell ------------------------------------------------------------------------ On Thu, 31 Mar 2005, Thomas Baker wrote: > -- "Access" is used in other DCMI definitions to mean > something different. In particular, "accessRights" is > about who can "access" a resource more in the sense of > "reach and use". Hmmm... actually, I disagree with this. Access Rights is about whether someone has rights to obtain (a copy of) the resource. It is not primarily about 'use' I don't think? So, for example, access to a bit of shareware software may be free provided that a registration process is gone thru but the usage of that software may be limited by licence to 1 month's use. Access Rights is about the former but not about the latter in my view. In DCMI terms, the latter is now covered by License. As an aside, given your dislike of defining Accessibility using the word 'access', I note that in the definition of Access Rights we do not really define what we mean by access (which is used in both the definition and the comment). Oh well :-( > Definition: A statement about the ease with which > the resource can be obtained or used. Sorry, but my personal view is that replacing 'accessed' by 'obtained' here really doesn't help much. In fact, the combination of 'obtained' and 'or' is actually worse, since it allows a statement to be made only about how easy it is to obtain the resource - which IMHO is not necessarily an 'accessibility' statement at all. In any case, I thought you wanted to differentiate the 'access' in accessibility from the 'access' in access rights. By using 'obtain and use' you made them exactly the same ('reach and use')?? If access means the same in both cases, why not just use 'access' in both? So, I would prefer to stick with 'accessed and/or used' with 'obtained and/or used' being second best. I quite like your comment, though I note that having removed 'accessed' from the definition, it feels odd to me to start with 'Ease of access encompasses ...'?? > Comment: Ease of access encompasses the ability to > perceive, understand, navigate, or interact with a > resource -- digital or physical -- regardless of the > technology being used. For example, this element may > be used for statements about the accessibility of a > resource to people who are permanently or temporarily > disabled. Users wishing to associate this element > with a description of a resource from the standpoint > of accessibility -- a "related description" in terms > of the DCMI Abstract Model [CITE] -- should consider > expressing the value in a machine-readable language > such as the W3C Evaluation and Reporting Language > (EARL) [CITE]. The problem I think is that with both your definition and mine, the statement "The resource is freely available" is a valid value (given the definitions and without looking at the comments) but isn't what we mean by accessibility. A resource can be 'open access' but inaccessible. I think we need to spell out what 'access' means in the context of accessibility in the definition, rather than in the comment. So, re-casting your comment slightly gives... "A statement about the ease with which it is possible to access, use, interact with or comprehend the resource"? And... for the record, I still think that this, and the first sentence of your comment, is just as much a definition of 'usability' as a definition of 'accessibility'. It is the 'regardless of the technology being used' bit that is critical here IMHO, and therefore that bit should remain in the definition. Which I think leaves my preferred option as something like "A statement about the ease with which it is possible to access, use, interact with or comprehend the resource, regardless of the technology being used" Sorry :-( ------------------------------------------------------------------------ Date: Thu, 31 Mar 2005 12:04:40 +0100 From: Pete Johnston ------------------------------------------------------------------------ I was keeping out of these discussions, but I skimmed Tom's proposed definition as it joined my email backlog and my reaction was similar to Andy's. I particularly agree with this point: > A resource can be 'open access' but inaccessible. I don't think "accessibility" (as intended in the initial property proposal) was about accessing-as-obtaining a resource, "getting to" the resource, if you like. The initial definition proposed in http://www.ozewai.org/DC-term-proposal/prop-reqs-table2.html was: ==== A reference to a machine-readable profile that describes the qualities of a resource that can be used to match the needs and preferences of a user as expressed in a machine-readable user profile. ==== The proposal referenced the IMS Accessibility work, and it may be useful to look at section 3 of http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.htm l for an idea of what "qualities of the resource" were in mind: === # Access Modality: Whether the user requires vision, hearing, touch and/or text literacy to access the resource. # Adaptability: How amenable the resource is to transformation of the display and whether the method of control is flexible (display transformability and control flexibility). # Equivalent: Whether there is a known equivalent alternative. === It seems fairly clearly about accessing-as-using the resource, "getting into" the resource, once I have "obtained" it - though of course the description of those attributes that condition access-as-use may be used to discover the resource in the first place. I think access-as-obtain and access-as-use are different things, even if the word "access" is often used to express both notions, and - somehow! ;-) - the definition of the new property needs to reflect that distinction. ------------------------------------------------------------------------ Date: Thu, 31 Mar 2005 16:13:39 +0200 From: Thomas Baker ------------------------------------------------------------------------ On Thu, Mar 31, 2005 at 11:14:26AM +0100, Andy Powell wrote: > >-- "Access" is used in other DCMI definitions to mean > > something different. In particular, "accessRights" is > > about who can "access" a resource more in the sense of > > "reach and use". > > Hmmm... actually, I disagree with this. Access Rights is about whether > someone has rights to obtain (a copy of) the resource. It is not > primarily about 'use' I don't think? ... Okay, I agree; point taken. > As an aside, given your dislike of defining Accessibility using the word > 'access', I note that in the definition of Access Rights we do not really > define what we mean by access (which is used in both the definition and > the comment). Oh well :-( Right... -- and I figured that using it in two different ways in two different definitions without defining it even once might be going a bit too far... ;-) > > Definition: A statement about the ease with which > > the resource can be obtained or used. > > Sorry, but my personal view is that replacing 'accessed' by 'obtained' > here really doesn't help much. In fact, the combination of 'obtained' and > 'or' is actually worse, since it allows a statement to be made only about > how easy it is to obtain the resource - which IMHO is not necessarily an > 'accessibility' statement at all. Hmm, good point. > In any case, I thought you wanted to differentiate the 'access' in > accessibility from the 'access' in access rights. By using 'obtain and > use' you made them exactly the same ('reach and use')?? If access means > the same in both cases, why not just use 'access' in both? > > So, I would prefer to stick with 'accessed and/or used' with 'obtained > and/or used' being second best. Hmm, is Accessibility really about "obtaining" at all...? > A resource can be 'open access' but inaccessible. > > I think we need to spell out what 'access' means in the context of > accessibility in the definition, rather than in the comment. So, > re-casting your comment slightly gives... > > "A statement about the ease with which it is possible to access, use, > interact with or comprehend the resource"? Okay, I like this. I'm just wondering whether the word "access" is really necessary... > And... for the record, I still think that this, and the first sentence of > your comment, is just as much a definition of 'usability' as a definition > of 'accessibility'. It is the 'regardless of the technology being used' > bit that is critical here IMHO, and therefore that bit should remain in > the definition. Okay, but is there really any reason why the element could not or should not be called "usability" (except for the obvious fact that it was proposed by a community that talks about "accessibility")? Typing "usability studies" into Google, right near the top I see a report on "usability tests with users with disabilities" filed under "accessibility". > Which I think leaves my preferred option as something like > > "A statement about the ease with which it is possible to access, use, > interact with or comprehend the resource, regardless of the technology > being used" > > Sorry :-( It is still not clear to me why the definition needs to refer to "technology" because, to me, there is nothing in the phrase "to access, use, interact with or comprehend the resource" which implies that technology is being used at all. So my suggestion would be to use your definition, but minus "access" and minus "regardless...": A statement about the ease with which it is possible to use, interact with or comprehend the resource. ------------------------------------------------------------------------ Date: Thu, 31 Mar 2005 16:28:00 +0200 From: Thomas Baker ------------------------------------------------------------------------ On Thu, Mar 31, 2005 at 12:04:40PM +0100, Pete Johnston wrote: > I particularly agree with this point: > > > A resource can be 'open access' but inaccessible. > > I don't think "accessibility" (as intended in the initial property > proposal) was about accessing-as-obtaining a resource, "getting to" the > resource, if you like. ... Yes, I agree with this. > for an idea of what "qualities of the resource" were in mind: > > === > # Access Modality: Whether the user requires vision, hearing, touch > and/or text literacy to access the resource. > # Adaptability: How amenable the resource is to transformation of the > display and whether the method of control is flexible (display > transformability and control flexibility). > # Equivalent: Whether there is a known equivalent alternative. > === > > It seems fairly clearly about accessing-as-using the resource, "getting > into" the resource, once I have "obtained" it - though of course the > description of those attributes that condition access-as-use may be used > to discover the resource in the first place. This is helpful. Nothing in there about "obtaining" in the sense of "discovering" or "fetching". Hmm, except perhaps with regard to equivalent alternatives. > I think access-as-obtain and access-as-use are different things, even if > the word "access" is often used to express both notions, and - somehow! > ;-) - the definition of the new property needs to reflect that > distinction. Yes, that states the contrast nicely. Since we have already used "access" in its "obtain" meaning for accessRights, using it in the definition for Accessibility arguably muddies the waters by implying that "obtaining" the resource is part of what Accessibility is about. Again: A statement about the ease with which it is possible to use, interact with or comprehend the resource. ------------------------------------------------------------------------ Date: Thu, 31 Mar 2005 16:34:00 +0100 From: Andy Powell Subject: Re: "Accessibility" decision - proposed wording ------------------------------------------------------------------------ I don't know about anyone else, but I would find it helpful to see some example values for Accessibility, as intended by the proposers. Can we ask Liddy to supply some? Were there examples in the original proposal? We know that EARL fits in somewhere, but if I'm honest, I don't really know what an EARL statement looks like or does! My understanding is that EARL is a language for recording the conformance of a resource against a particular benchmark. So, in this case, EARL would presumably be used to make a staement about whether a resource conforms to WAI or not? >From the EARL homepage... --- cut --- EARL would initially be a means for expressing in a machine readable form ... * Results of evaluating web pages and web sites against the Web Accessibility Content Guidelines --- cut --- It is therefore arguable whether the definition should be "A statement about the ease with which it is possible ..." - rather it should be "A statement about the conformance of a resource to a particular accessibility benchmark" or words to that effect. But it is also possible that the intended 'value' of Accessibility is a complete chunk of XML that conforms to the IMS Accessibility spec. If so, then things get quite complex because the IMS spec references EARL statements itself (several times). As hinted in the original wording of the definition of Accessibility A description of the qualities of the resource in terms of control, display and content that can be used to match the needs and preferences of a user. the value looks to be a second (albeit fairly long and complex) description of the resource - but one that uses attributes (qualities!) of the resource that are relevant in the context of how accessibile it is likely to be - colour, use of images, etc. Defining dcterms:accessibility as a term which links to a separate description of the resource is a bit like creating a new term called dcterms:libraryOrientedDescription and then using it to link to a MARC record. As PeteJ has argued in the past, if there are useful attributes defined in the IMS Accessibility spec then (provided they are declared as RDF properties) we can use them directly in our descriptions - we don't need a new Accessibility property in order to do that. (Just as we are doing with the MARC relator terms from the library world). So, I must admit that I'm totally confused about what we are achieving (or even trying to achieve) here. My personal view is that it looks as though we were wrong to approve this term in Shanghai - and that it is better to admit that now than to move forward on shaky ground. I urge us not to do anything more on this without involving Liddy and without getting some concrete example values from her. ------------------------------------------------------------------------ Date: Thu, 31 Mar 2005 17:07:55 +0100 From: Pete Johnston ------------------------------------------------------------------------ Andy said: > I don't know about anyone else, but I would find it helpful > to see some example values for Accessibility, as intended by > the proposers. Can we ask Liddy to supply some? Were there > examples in the original proposal? The "Example" entry in the table in http://www.ozewai.org/DC-term-proposal/prop-reqs-table2.html refers to IMS AccMD XML, and the "Comment" referred to http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_bestv1p0.html But neither illustrates exactly how it should be implemented. > We know that EARL fits in somewhere, but if I'm honest, I > don't really know what an EARL statement looks like or does! > My understanding is that EARL is a language for recording the > conformance of a resource against a particular benchmark. > So, in this case, EARL would presumably be used to make a > staement about whether a resource conforms to WAI or not? > > From the EARL homepage... > > --- cut --- > EARL would initially be a means for expressing in a machine > readable form > ... > > * Results of evaluating web pages and web sites against the Web > Accessibility Content Guidelines > --- cut --- > > It is therefore arguable whether the definition should be "A > statement about the ease with which it is possible ..." - > rather it should be "A statement about the conformance of a > resource to a particular accessibility benchmark" or words to > that effect. The EARL 1.0 working draft spec http://www.w3.org/TR/EARL10/ didn't seem to be linked from the EARL home page http://www.w3.org/2001/03/earl/ :-( FWIW, EARL development now seems to be under http://www.w3.org/WAI/ER/ Anyway, down in section 3 of EARL 1.0, there is an example of an EARL assertion http://www.w3.org/TR/EARL10/#assertion (more below) > But it is also possible that the intended 'value' of > Accessibility is a complete chunk of XML that conforms to the > IMS Accessibility spec. If so, then things get quite complex > because the IMS spec references EARL statements itself > (several times). > > As hinted in the original wording of the definition of Accessibility > > A description of the qualities of the resource in terms of control, > display and content that can be used to match the needs and > preferences > of a user. > > the value looks to be a second (albeit fairly long and > complex) description of the resource - but one that uses > attributes (qualities!) of the resource that are relevant in > the context of how accessibile it is likely to be - colour, > use of images, etc. > > Defining dcterms:accessibility as a term which links to a > separate description of the resource is a bit like creating a > new term called dcterms:libraryOrientedDescription and then > using it to link to a MARC record. > > As PeteJ has argued in the past, if there are useful > attributes defined in the IMS Accessibility spec then > (provided they are declared as RDF > properties) we can use them directly in our descriptions - we > don't need a new Accessibility property in order to do that. > (Just as we are doing with the MARC relator terms from the > library world). I noticed that that (newer?) EARL 1.0 example is modelled slightly differently from the (older?) example shown on the EARL home page. That old example seemed to be a simple resource:X earl:passes test:Y (with reification to say who asserted that) The (newer?) model sidesteps reification (I think) and has the "assertor" (and also the subject resource, the test, the result etc) as a property of a resource of type earl:Assertion. So I can see that this new EARL 1.0 model would fit less cleanly into the DC "statements-about-the-subject-resource" framework (there is no longer an earl:passes property involved), so on this basis, there may be more grounds for that pointer-to-EARL-stuff property. > So, I must admit that I'm totally confused about what we are > achieving (or even trying to achieve) here. > > My personal view is that it looks as though we were wrong to > approve this term in Shanghai - and that it is better to > admit that now than to move forward on shaky ground. > > I urge us not to do anything more on this without involving > Liddy and without getting some concrete example values from her. Yes, I agree. The W3C documentation on this stuff does seem to be rather fragmented, and even when I manage to find stuff, I end up guessing about what is the most current. And yes, I would just like to see a simple concrete example of how a DC description and an EARL assertion are used together and exactly where the proposed property fits in.