Re: ERT WG comment on POWDER documents

Shadi,

I'm just going through all our comments and making sure everything is 
ship shape so I can make a transition request to PR in the near future. 
I see to my horror that this e-mail was never sent to you. I drafted it, 
sent it to the group for comment and mentioned it to you at TPAC last 
year but, well, it never got sent to you. So, here's the full response 
to the comments you made for which we were, of course, very grateful.

Best wishes

Phil.

Shadi Abou-Zahra wrote:

Dear POWDER WG,

Apologies for the belated response, we hope you can still consider these 
comments and questions from ERT WG:

Yes, thanks Shadi, we're still dealing with comments.

#1. Referring to technical standards for labeling, such as WCAG 2.0

We understand that the following type of code could be used to refer to 
a technical standard that the POWDER label implies:

<descriptorset>
  <acc:guidelines>WCAG 2.0</acc:guidelines>
  <acc:level>AA</acc:level>
  <displaytext>Everything on example.com is red and square>/displaytext>
  <displayicon src="http://authority.example.org/icon.png" />
  <typeof src="http://www.example.org/vocabulary#WCAG20-AA" />
  <seealso src="http://www.w3.org/TR/WCAG20/" />
</descriptorset>

Comment: have you considered a specific property that can be used to 
reference such as technical standard rather than "seealso"?

You've used the typeof and seealso elements exactly as intended here. 
The typeof element says that each resource described by this descriptor 
set (typically each element within an IRI set) is an instance of 
http://www.example.org/vocabulary#WCAG20-AA". which looks as if that's 
what you mean. If the user agent wants more information then
there's more at the URI in the seealso element.
We did toy with a 'complies with' property that could have been used to 
refer to tech standards, codes of conduct etc. but felt in the end that 
typeof (shorthand for
rdf:type) was sufficient. Therefore, we are minded not to introduce such 
a term.

Actually, this perhaps touches on an issue we are discussing - whether 
the seealso
element becomes a predicate and object for each described resource or is 
a property
of the descriptor set itself.

#2. Referring to test reports to validate or justify the labels

We understand that the following type of code could be used to refer to 
test reports, such as EARL reports that contain test results:

<attribution>
  <issuedby src="http://www.example.com/company.rdf#me" />
  <issued>2008-06-25T00:00:00</issued>
  <supportedby src="http://validator.example.org/report.earl" />
</attribution>

Correct.
Comment: have you considered a specific property that can be used to 
reference such test reports rather than "supportedby"?

Again, yes we did but felt that supportedby was sufficient. The attribution
element in a POWDER doc can contain any element (it's XML!) so it would 
be possible to
include a more specific term if required. However, the attributed party
is the one making the claims in the DR(s). A test result would clearly 
be relevant but it
has its own attribution mechanism which may or may not lead to the same
individual or entity.

#3. Methodology used for concluding claims and labels

In some cases an documented methodology is used to evaluate the 
conformance of Web content to a technical standard. For example, the 
Unified Web Evaluation Methodology (UWEM) is a publicly documented 
evaluation methodology for Web accessibility (it evaluates conformance 
to WCAG 1.0). We understand that also in this case the "seealso" 
attribute is used to refer to such methodologies. Have you considered a 
specific property to reference evaluation/conformance methodologies?

Not specifically. We've been careful to make POWDER as generic as 
possible. It is designed so that any sort of vocabulary may be used and 
this may or may not refer to test methodologies. I think this would fall
very much into the application-specific category. You can do it, yes, but
it doesn't need to be a core part of POWDER (but if we somehow prevented 
it then clearly, that would be a bad design)


#4. Contact point or complaint mechanism for labels

Many labeling schemes require some form of contact point or complaint 
mechanism, for example if an end-user feels that the claim is false or 
that the label is otherwise misused. Often these complaint forms are 
linked from the graphical icon on the Web pages. Have you considered a 
specific property to supplement "displaytext" and "displayicon", that 
provides a link to the feedback resource?

No. The idea is that the RDF that describes the author should
contain or lead to this information. We provide the wdrs:authenticate 
property [1] for this purpose. It is deliberately generic so that the 
object might be an HTML page, a WSDL file or anything else (or lots
of different representations through conneg of course!)

We don't envisage the display text or display icons being presented in a 
browser window, rather they would be in the browser chrome or some other
UA. Furthermore, authentication of the DR should be carried out
automatically, not through a human activation (which is much more open
to spoofing).
Now I'm worried. You've taken the trouble to go through the document and 
have picked
up how to use POWDER for describing Web sites in terms of accessibility 
- which has always been an important use case for us. But in each of 
your points we're resolved 'no.'
Hmm, it's perhaps a tad impolite of us!

But do you see any of these issues as a barrier to the sort of uses you 
envisage?
Phil.


[1] http://www.w3.org/TR/2008/WD-powder-dr-20080815/#discover





Shadi Abou-Zahra wrote:
>
> Dear POWDER WG,
>
> Apologies for the belated response, we hope you can still consider 
> these comments and questions from ERT WG:
>
> #1. Referring to technical standards for labeling, such as WCAG 2.0
>
> We understand that the following type of code could be used to refer 
> to a technical standard that the POWDER label implies:
>
> <descriptorset>
>    <acc:guidelines>WCAG 2.0</acc:guidelines>
>    <acc:level>AA</acc:level>
>    <displaytext>Everything on example.com is red and square>/displaytext>
>    <displayicon src="http://authority.example.org/icon.png" />
>    <typeof src="http://www.example.org/vocabulary#WCAG20-AA" />
>    <seealso src="http://www.w3.org/TR/WCAG20/" />
> </descriptorset>
>
> Comment: have you considered a specific property that can be used to 
> reference such as technical standard rather than "seealso"?
>
>
> #2. Referring to test reports to validate or justify the labels
>
> We understand that the following type of code could be used to refer 
> to test reports, such as EARL reports that contain test results:
>
> <attribution>
>    <issuedby src="http://www.example.com/company.rdf#me" />
>    <issued>2008-06-25T00:00:00</issued>
>    <supportedby src="http://validator.example.org/report.earl" />
> </attribution>
>
> Comment: have you considered a specific property that can be used to 
> reference such test reports rather than "supportedby"?
>
>
> #3. Methodology used for concluding claims and labels
>
> In some cases an documented methodology is used to evaluate the 
> conformance of Web content to a technical standard. For example, the 
> Unified Web Evaluation Methodology (UWEM) is a publicly documented 
> evaluation methodology for Web accessibility (it evaluates conformance 
> to WCAG 1.0). We understand that also in this case the "seealso" 
> attribute is used to refer to such methodologies. Have you considered 
> a specific property to reference evaluation/conformance methodologies?
>
>
> #4. Contact point or complaint mechanism for labels
>
> Many labeling schemes require some form of contact point or complaint 
> mechanism, for example if an end-user feels that the claim is false or 
> that the label is otherwise misused. Often these complaint forms are 
> linked from the graphical icon on the Web pages. Have you considered a 
> specific property to supplement "displaytext" and "displayicon", that 
> provides a link to the feedback resource?
>
>
> Regards,
>   Shadi Abou-Zahra for ERT WG
>


-- 
Phil Archer
w. http://philarcher.org/

Received on Monday, 26 January 2009 14:15:32 UTC