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

Re: Comments on latest EARL Schema draft

From: Michael A Squillace <masquill@us.ibm.com>
Date: Tue, 23 Jun 2009 07:48:27 -0500
To: public-wai-ert@w3.org
Message-ID: <OF19FDC43E.04D2C75D-ON852575DE.00464FA9-862575DE.00465BFF@us.ibm.com>

"Rather than specifying only an earl:Assertor type, it is recommended
that one of the following types be added:"
--> Mike Squillace
IBM Human Ability and Accessibility Center


External: http://www.ibm.com/able
Internal: http://w3.ibm.com/able

             Johannes Koch                                                 
             t.fraunhofer.de>                                           To 
             Sent by:                  ERT WG <public-wai-ert@w3.org>      
             public-wai-ert-re                                          cc 
                                       Re: Comments on latest EARL Schema  
             06/23/2009 03:39          draft                               

Michael A Squillace schrieb:

> 2. regarding the Assertor class: First, the last example markup looks
> suspect:
> <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
> testing</dc:description>
>   <earl:mainAssertor rdf:resource="http://www.example.org/people/#bob"/>
>   <foaf:member rdf:resource="http://www.example.org/tool/#cool"/>
> </foaf:Agent>
> 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.

Slightly different: A resource acting as subject in a triple with a
foaf:member property (or subproperty of foaf:member) by RDFS _has_ the
type foaf:Group. Specifying a domain does not specify a constraint. It
adds a type.

> 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:group, and earl:software as the possible "refinements." Actually, we

> want to use some combination of these and wrap them in a foaf:group,
> 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
> 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
> spec.

Taking into account the RDFS information, the resource <#assertor> has
the following types:

* foaf:Agent (by using the foaf:Agent element type in RDF/XML)
* earl:Assertor (by domain of earl:mainAssertor)
* foaf:Group (by domain of foaf:member, inherited domain of

I think the wording "Rather than using the generic earl:Assertor class
directly" sounds too XML-like (XML element types). We want to define an
RDF-based vocabulary. So we should think in RDF, not in XML.

What about the following?

"Rather than specifying only an earl:Assertor type, it is recommended
that one of the following types be added:"

Johannes Koch
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628    Fax: +49-2241-142065

(image/gif attachment: graycol.gif)

(image/gif attachment: pic06545.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 23 June 2009 12:49:11 UTC

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