W3C home > Mailing lists > Public > public-wai-ert@w3.org > June 2009

Comments on latest EARL Schema draft

From: Michael A Squillace <masquill@us.ibm.com>
Date: Mon, 22 Jun 2009 12:51:40 -0500
To: "ERT WG " <public-wai-ert@w3.org>
Message-ID: <OF9347FE25.00D1F1C6-ON852575DD.005B3A3C-862575DD.0061E83E@us.ibm.com>
I have the following remarks regarding the 10 June 2009 editor's draft of 
the EARL 1.0 Schema specification:


1. document needs to reflect the new resolution to define EARL as a 
vocabulary defined in multiple specs/notes. This schema needs to be 
understood as defining the core terms of that vocabulary. For example, 
portions of the abstract and section 1, introduction, make it sound as if 
this is the only document that defines terms for the EARL vocabulary.

2. regarding the Assertor class: First, the last example markup looks 

<foaf:Agent rdf:about="#assertor">
  <dc:title xml:lang="en">Bob using Cool Tool</dc:title>
  <dc:description xml:lang="en">Bob doing semi-automated 
  <earl:mainAssertor rdf:resource="http://www.example.org/people/#bob"/>
  <foaf:member rdf:resource="http://www.example.org/tool/#cool"/>

I think we want to define a foaf:group, not foaf:agent here. This makes 
more sense intuitively and is also consistent with the definition of the 
earl:mainAssertor property, a subproperty of foaf:member which can only 
have a subject of foaf:group. Related to this point, the "Related Classes" 
section states that, "Rather than using the generic earl:Assertor class 
directly, it is recommended that one of the following refinements be 
employed," and goes on to list foaf:person, foaf:agent, foaf:organization, 
foaf:group, and earl:software as the possible "refinements." Actually, we 
want to use some combination of these and wrap them in a foaf:group, which 
represents the earl:Assertor; these are not subclasses in any way of the 
earl:Assertor class. (Part of the problem is with the use of the word 
'refinement', which in the description of earl:mainAssertor seems to imply 
subProperty of, whereas here we do not want to indicate any inheritence 
relation.) Some of this might be clarified by requirement #4 in the 
"Conforming Reports" section, but I think there is still some confusion 
between what counts as an assertor in general and what is allowed by the 

3. In response to editors notes 5 and 6, it looks as if the group is 
converging on the four conformance levels we have been discussing on the 
mailing list: 


so that the answer to both notes is no, unless the consumer or producer is 
trying to conform at the higher levels. Partial or core conformance would 
not require handling of the other parts of the vocabulary. This also means 
a rewording for section 4.4 and removing requirement #3 from both the 
consumer and producer requirement list.
--> Mike Squillace
IBM Human Ability and Accessibility Center


External: http://www.ibm.com/able
Internal: http://w3.ibm.com/able
Received on Monday, 22 June 2009 17:52:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:58 UTC