This document describes the formal schema of the Evaluation and Report Language (EARL) 1.0. The Evaluation and Report Language is a standardized vocabulary to express test results. The primary motivation for developing this language is to facilitate the exchange of test results between Web accessibility evaluation tools in a vendor neutral and platform independent format. It also provides reusable vocabulary for generic quality assurance and validation purposes. While this document focuses on the technical details of the specification, a companion document [Guide] describes the motivations for EARL and provides a tutorial introduction to its use.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This 23 March 2007 Last Call Working Draft of the Evaluation and Report Language (EARL) 1.0 Schema is an update of the previous EARL 1.0 Working Draft of 27 September 2006. It meets the requirements specified in the Requirements for the Evaluation and Report Language (EARL) 1.0, and incorporates change requests received since the September 2006 Working Draft. In particular, this draft implements the decisions of the ERT Working Group at its face to face meeting in February 2007 (see history of document changes). This document is intended to be published and maintained as a W3C Recommendation after review and refinement.

The ERT Working Group believes it has addressed all issues brought forth through previous Working Draft iterations and is looking for feedback on the maturity of this language from the broadest audience possible. Specifically, the Working Group encourages feedback about this document, Evaluation and Report Language (EARL) 1.0 Schema, by developers and researchers who have interest in software-supported evaluation and validation of Web sites. Feedback from developers and researchers who have interest in Semantic Web technologies for content description, annotation, and adaptation is also strongly encouraged. Information on the W3C document stages following Last Call Working Draft is available at How WAI Develops Accessibility Guidelines through the W3C Process.

Please send comments on this document by 20 April 2007 at the latest to the public email list of the working group public-wai-ert@w3.org. The archives of the working group mailing list are publicly available.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the Evaluation and Repair Tools Working Group as part of the WAI Technical Activity.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

  1. Introduction (Non-Normative)
  2. Core Vocabulary
  3. Conformance


  1. EARL 1.0 Schema in RDF/XML
  2. EARL 1.0 Terms (Non-Normative)
  3. Document Changes (Non-Normative)
  4. References (Non-Normative)
  5. Contributors (Non-Normative)

1. Introduction (Non-Normative)

[Editor's note: this section will be synchronized with the EARL 1.0 Guide [Guide] as it is being developed.]

The Evaluation and Report Language (EARL) is a format to express test results. Test results include bug reports, test suite evaluations, and conformance claims. The test subject might be a Web site, an authoring tool, a user agent or some other entity. Thus, EARL is flexible. It enables any person, entity, or organization to state test results for any thing tested against any set of criteria.

Stating test results in EARL creates a variety of opportunities. The data can be:

A companion document [Guide] to this specification provides more introductory material and explanation of the use cases for EARL.

1.1. Structure of EARL Results (Non-Normative)

EARL statements contain the following types of information:

This can include information about who or what ran the test. For example human evaluators, automated accessibility checkers, or combinations of these.
Test Subject
This can include Web content (such as Web pages, videos, applets, etc.), software (such as accessibility checkers, validators, user agents, etc.), or other things being tested.
Test Criterion
What are we evaluating the test subject against? This could be a specification, a set of guidelines, a test from a test suite, or some other testable statement.
Test Result
What was the outcome of the test? Which parts of the test subject were significant for the outcome of the test?

Prose examples that demonstrate the above structure:

Example 1: A person carries out a manual evaluation of a Web page against a Test Criterion.

Bob B. Bobbington
Test Subject
A Web page located at http://www.example.org/page.html
Test Criterion
Checkpoint 1.1 of the Web Content Accessibility Guidelines 1.0
Test Result

Example 2: A software carries out automated evaluation of a Web page against a Test Criterion.

The W3C Markup Validator located at http://validator.w3.org/
Test Subject
The XHTML returned from a GET request to the URI http://www.example.org/page.html at 2004-04-14T14:00:04+1000
Test Criterion
The validity of the XHTML code
Test Result
Failed, the <li> element on line 53, char 7 was not closed.

Note: It is important to consider potential security and privacy issues when using EARL. For instance, the test results expressed in EARL could potentially contain sensitive information such as the internal directory structure of a Web server, parts of restricted Web pages, or testing modalities. The scope of this document is limited to defining the core EARL vocabulary, security and privacy considerations need to be made at the application level. For example, certain parts of the data may be restricted to appropriate user permissions or obfuscated.

1.2. Document Conventions and Audience

Editorial Comments (Non-Normative)

There are a few known issues in this draft, that need to be resolved in future drafts. Comments are specifically requested on any of these issues, which are marked as follows:

[Editor's note: the working group has some specific questions, or areas on which they request feedback.]

This subsection will be removed from the final version of the document, and editorial comments will have been resolved.

Audience of this document (Non-Normative)

This document is intended as a brief complete specification of the EARL 1.0 vocabulary. It assumes that the reader is familiar with the ideas of RDF and can read its XML serialization as bare code. The assumed audience is developers who are implementing EARL in software or processes, or are seeking to understand the ideas, models, or properties and classes used in the EARL vocabulary. Readers who would like a more tutorial introduction to the language, with more explanation of its foreseen use cases, are referred to the EARL 1.0 Guide [Guide]. Readers who wish to understand more about RDF are advised to consider reading a general introduction, or reading the RDF Primer [RDF-PRIMER].


The keywords must, required, recommended, should, may, and optional are used in accordance with RFC 2119 [RFC2119].


The namespace for EARL as specified in this draft is http://www.w3.org/ns/earl# [Editor's note: namespace document will be added at this URI pending WG decision].

Where RDF terms are used in their abbreviated form (e.g. Assertion or foaf:Person), if no namespace is provided the term is in the EARL namespace. The following prefixes are used in examples throughout this document:

The EARL namespace http://www.w3.org/ns/earl# which is described in this document
The Dublin Core elements namespace http://purl.org/dc/elements/1.1/ whose terms are described in [DC]
The Dublin Core terms namespace http://purl.org/dc/terms/ described at [DCT]
The FOAF namespace http://xmlns.com/foaf/0.1/ which is also where the terms are described [FOAF]
The HTTP Vocabulary in RDF namespace http://www.w3.org/2006/http# described in [HTTP]
The OWL namespace http://www.w3.org/2002/07/owl# described in [OWL]
The Pointer Methods in RDF namespace described in [Pointers]
The RDF namespace http://www.w3.org/1999/02/22-rdf-syntax-ns# described in [RDF]
The RDF Schema namespace http://www.w3.org/2000/01/rdf-schema# described in [RDFS]
The XMLS namespace http://www.w3.org/2001/XMLSchema# described in [XMLS]

1.3. About RDF Vocabularies (Non-Normative)

EARL is defined as an RDF vocabulary. The Resource Description Framework (RDF) is a general-purpose language for describing information in a way that is machine-understandable.

EARL is an RDF vocabulary used to make statements about how a resource performed against a test. In common with other RDF it assumes that other vocabularies will be used as appropriate.

For more information on RDF, please refer to the following references:

2. Core Vocabulary

The EARL 1.0 specification defines an RDF Vocabulary that consists of classes and properties. This section describes the core vocabulary and gives brief examples of its usage. Later sections describe the conformance to EARL 1.0 and list the EARL 1.0 Terms.

2.1. Assertion

An Assertion is a statement about the results of performing a test. The earl:Assertion class relates the required instances of an Assertor, Test Subject, Test Criterion, and Test Result to a specific Assertion. Each Assertion represents a single statement about a test that was carried out, see the section on conformance for more information about the EARL model.

An Assertion must have exactly one instance of each of the following properties:

The Assertor is a human or software, or groups of these, that determine the result.
The thing that is being tested against some test criterion is the Subject of the assertion.
The Test Criterion that is used to test a Test Subject of the assertion.
The Result of the test - whether the subject passes or fails the test criterion (or there is some other result).

An Assertion may also include at most one instance of the following optional property:

The mode in which the test was performed - as an automated computer process, by a human, or otherwise.

Example 3: Instance of an assertion expressed as an RDF/XML fragment.

<earl:Assertion rdf:about="#assertion">
  <earl:assertedBy rdf:resource="#assertor"/>
  <earl:subject rdf:resource="#subject"/>
  <earl:test rdf:resource="#testcase"/>
  <earl:result rdf:resource="#result"/>

2.2. Assertor

An Assertor determines the results of a test (i.e. an assertor asserts and assertion). An earl:Assertor instance must belong to one of the following types:

2.2.1. Single Assertor

A Single Assertor is a single entity responsible for making the Assertion. Such an entity could be a single human, tool, or whole groups such as organizations. An earl:SingleAssertor instance must be one of the following types:

The assertor is an Agent, as defined in [FOAF]. Any subclass of foaf:Agent can be used, however it is recommended to use the widely deployed foaf:Person and foaf:Organization classes as follows:
The assertor is a human being. There should be identifying information including a name, and a uniquely identifying property such as an email address or preferably an encrypted email address. The properties foaf:name, foaf:mbox and foaf:mbox_sha1sum should be used to provide this information.
The assertor represents an organization. There should be identifying information including a name, and a uniquely identifying property such as a home page. The properties foaf:name, foaf:homepage should be used to provide this information.
The assertor is a piece of Software, such as a black box testing tool of some sort or an evaluation tool.

Example 4: A Single Assertor that is a person called Bob B. Bobbington.

<foaf:Person rdf:about="#bob">
  <foaf:name>Bob B. Bobbington</foaf:name>
  <foaf:mbox rdf:resource="mailto:bob@example.org"/>

Example 5: A Single Assertor that is a piece of software called Cool Tool.

<earl:Software rdf:about="#tool">
  <dc:title xml:lang="en">Cool Tool</dc:title>
  <dc:description xml:lang="en">My favorite tool!</dc:description>
  <foaf:homepage rdf:resource="http://example.org/tools/#cool"/>

2.2.2. Compound Assertor

A Compound Assertor is a group of two or more entities that are responsible for making an assertion. Each group of entities must have at least one primary Assertor identified by the earl:mainAssertor property, and may, have secondary Assertor identified by the earl:helpAssertor property, as well as optional title and description identified by the [DC] dc:title and dc:description properties respectively.

Note: since the range of both the earl:mainAssertor and the earl:helpAssertor properties of the Compound Assertor reference earl:Assertor classes, these instances can be a Person, Agent, Software, or recursively another Compound Assertor. If all entities in a group contributed equally to determining the result, for example a group of humans carrying out end-user testing of accessibility features, then these are all considered main assertors without any help assertors.

Example 6: A Compound Assertor of the person from example 4 using the software from example 5.

<earl:compoundAssertor 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="#bob"/>
  <earl:helpAssertor rdf:resource="#tool"/>

2.3. Test Subject

The Test Subject is the class of things that have been tested. This class is intentionally generic to serve a wide variety of usages. For more specific use cases, the Content or Software classes should be used in place.

The earl:TestSubject class may have instances of the following properties:

Human readable title for the subject
Human readable description of the subject
Date to describe the subject as closely as possible (see not below)
Relationship to other subjects that are part of this subject
Relationship to other subjects of which this subject is a part of

Note: the dc:date property is used to describe the test subject as a means of versioning it for later comparison with other versions of the content. The date should reflect the creation date of the subject if available, or otherwise the date on which the subject was identified. The Content class makes more specific assumptions of the usage of this property.

Example 7: A group of pages that have been tested together as a single subject.

<earl:TestSubject rdf:about="http://www.example.org/">
  <dc:title xml:lang="en">example.org Web site</dc:title> 
  <dc:description xml:lang="en">Each page on the example.org Web site</dc:description> 
  <dct:hasPart rdf:resource="http://www.example.org/style.css"/> 
  <dct:hasPart rdf:resource="http://www.example.org/page1.html"/> 
  <dct:hasPart rdf:resource="http://www.example.org/page2.html"/> 
  <dct:hasPart rdf:resource="http://www.example.org/page3.html"/> 

2.4. Test Criterion

A Test Criterion is a testable statement, usually one that can be passed or failed. It is a super class for all types of tests including things such as validation requirements, code test cases, checkpoints from guidelines such as Web Content Accessibility Guidelines 1.0 [WCAG10], or others.

While the generic earl:TestCriterion class can be used directly, one of the following types should be used:

A higher-level requirement that is tested by executing one or more sub-tests. For example WCAG 1.0 Checkpoint 1.1 which is tested by executing several sub-tests and combining the results.
An atomic test, usually one that is a partial test for a requirement. For example, checking if an image has an alt attribute which could be part of testing WCAG 1.0 Checkpoint 1.1.

A Test Criterion may be a single test, or part of a larger compound test suite. These relations may be described using Dublin Core's dct:hasPart or dct:isPartOf properties. Additionally, a title or description for the Test Criterion may be included by using the Dublin Core dc:title or dc:description properties.

Note: where possible, the Test Criterion class should try to reuse publicly available and preferably commonly accepted URIs for test requirements and test cases. Reusing publicly available URIs such as these provided by WCAG facilitates the interoperability and exchange of reports between different tools.

[Editor's note: The earl:TestCriterion, earl:TestRequirement, and earl:TestCase classes are included for convenience, since this allows various useful properties to be described in simple standard RDF. The working group will deprecate these classes if they find an appropriate replacement from a language designed for describing Test Criterion (including test requirements and test cases), something which is beyond the scope of the current specification.]

Example 8: Description of a CSS 1 test case and its relationship to the test suite.

<earl:TestCase rdf:about="http://www.w3.org/Style/CSS/Test/CSS1/20070302/sec21.htm">
  <dc:title xml:lang="en">CSS 1 Test Suite: 2.1 anchor</dc:title>
  <dc:description xml:lang="en">Test for CSS 1 Section 2.1 Anchor pseudo-classes</dc:description>
  <dct:isPartOf rdf:resource="http://www.w3.org/Style/CSS/Test/CSS1/20070302/"/>

Example 9: Description of a CSS 1 requirement and its relationship to the specification.

<earl:TestRequirement rdf:about="http://www.w3.org/TR/REC-CSS1#anchor-pseudo-classes">
  <dc:title xml:lang="en">CSS 1 Section 2.1 Anchor pseudo-classes</dc:title>
  <dc:description xml:lang="en">Conformance to CSS 1 Section 2.1 Anchor pseudo-classes </dc:description>
  <dct:isPartOf rdf:resource="http://www.w3.org/TR/REC-CSS1"/>

2.5. Test Mode

The (optional) Test Mode information is used to simplify some commonly used queries on how the testing was carried out. When provided, it must reflect the information provided by the Assertor, and it must be exactly one of the following pre-defined values (or subclasses of them):

Where the test was performed based on a person's judgement. This includes the case where that judgement was aided through the use of a software tool, although this should be additionally noted through the earl:compoundAssertor class of the Assertor.
Where a software tool has carried out the test automatically without any human intervention.
Where a software tool was primarily responsible for generating a result, even if with some human assistance. This should be additionally noted through the earl:compoundAssertor class of the Assertor.
Where a combination of persons and/or software tools was used to carry out the test, but there is no detailed information about the primary responsibility for determining the outcome of the test. This includes when testing is carried out by organizations or groups of assertors, and the exact testing process is not disclosed.
This property was designed to cover assertions which are made by inference, for example based on several existing test results.

Example 10: The assertion from example 3 was carried out in semi-automatic mode.

<earl:Assertion rdf:about="#assertion">
  <earl:mode rdf:resource="http://www.w3.org/ns/earl#semiAutomatic"/> 

2.6. Test Result

The actual result of the test. It includes both machine-readable values as well as human-readable description of the results (typically error messages).

A Test Result must have exactly one instance of the earl:outcome property to provide a machine-readable Outcome Value value that describes the result. A Test Result should also include instances the following properties:

A short title for the result, for example the error code generated by an evaluation tool.
A human-readable text or markup (for example HTML included as an XML Literal), and should therefore include an identification for the natural language.

A Test Result may also include instances of the following properties:

Date on which the test was carried out (see also date of the Test Subject).
A Pointer identifies a location (or a set of locations) within the Test Subject of the same assertion. It is recommended to use several equivalent pointers in different format as described in the Pointer Methods in RDF [Pointers].
[Editor's note: the Pointer Methods in RDF document is currently under development by the ERT WG.]
Additional information beyond the description of the result. For example warnings or other informative messages that may help a reader better understand the result. It is recommended to use Literal values for such additional messages.

Example 11: A test result with a outcome of fail and a description of the problem in English, and encoded in XHTML format.

<earl:TestResult rdf:about="#result">
  <earl:outcome rdf:resource="http://www.w3.org/ns/earl#fail"/>
  <dc:title xml:lang="en">Invalid Markup (code #353)</dc:title>
  <dc:description rdf:parseType="Literal" xml:lang="en">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>The <code>table</code> element is not allowed to appear
        inside a <code>p</code> element</p>
  <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2006-08-13</dc:date>
  <earl:pointer rdf:resource="#xpointer"/>
  <earl:info rdf:parseType="Literal" xml:lang="en">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>It seems the <code>p</code> element has not been closed</p>

2.6.1. Outcome Value

The Outcome Value of a test must be one of the following pre-defined values (or subclasses of them):

An assertor claims a test passed successfully.
The Test Subject did not meet the Test Criterion.
An Assertor can not tell for sure what the outcome of the test is. Usually this happens when an automated test requires human judgement to make a definite decision.
The Test Criterion is not applicable to the given Test Subject.
Test has not been carried out. This is useful for reporting as well as for other uses of progress monitoring.

2.7. Software Tool

A Software Tool is any software such as an authoring tool, browser, or evaluation tool. Software should have a title using the Dublin Core property dc:title; and may have descriptions, version information, and a home page using the Dublin Core terms dc:description, dct:hasVersion, as well as the FOAF term foaf:homepage.

While the software class is often used to describe evaluation tool assertors, a software could also be a Test Subject (for example to test compliance of an authoring tool to the Authoring Tool Accessibility Guidelines). In this case, it inherits the optional properties dc:date, dct:isPartOf and dct:hasPart from the Test Subject class.

Example 12: The software which was an Assertor in example 5 could also be used as a Test Subject.

<earl:Assertion rdf:about="#assertion">
    <earl:Software rdf:about="#tool">
      <--// Note: the dc:title, dc:description, foaf:homepage, and dct:hasVersion 
            properties are already defined by the RDF code in example 5 //-->
      <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2005-06-25</dc:date> 
      <dct:isPartOf rdf:resource="http://example.org/tools/"/>
      <dct:hasPart rdf:resource="http://example.org/tools/cool/#module-1"/>

2.8. Content

The Content class describes some content that has been subject of testing. It takes into account the context under which the content was fetched, for example content type and language negotiation or similar factors for Web content that is served by HTTP. This class is intended to be used as a test subject but can be reused for other purposes (outside EARL) as well. The Content class should have instances of at least one of the following properties:

A copy of the actual source of the content that has been tested. This could include Literal, XML, or Data URI types depending on the content.
The context under which the content was fetched. It is recommended to use the HTTP Vocabulary in RDF [HTTP] to describe Web content served by HTTP.

In the usual case where the Content class is used as a Test Subject, it inherits the optional properties dc:date, dct:isPartOf and dct:hasPart from the Test Subject class. In this context, the dc:date property is used to describe the version of the content as closely as possible. In other words, it should reflect the last modified date if available, otherwise the creation date, or in worst case the date in which the content was retrieved for testing.

[Editor's note: the working group is looking for feedback on the earl:Content class, especially on its usage together with the HTTP Vocabulary in RDF.]

Example 13: The HTML page from Example 7 is recorded along with its HTTP headers.

<earl:Content rdf:about="http://www.example.org/page1.html">
  <earl:sourceCopy rdf:parseType="Literal" xml:lang="en">
    <html xmlns="http://www.w3.org/1999/xhtml">
      	<title>Hello World!</title>
        <p>Hello World!</p>
  <earl:context rdf:resource="#httpRequest"/>

3. Conformance

An EARL report is a set of instances of the Assertion class. Each assertion contains information about a single test that was carried out. EARL does not prescribe how to group tests into a report since this is highly application and end-user specific. For example, reports generated for Web developers may contain more detailed results in order to repair bugs while reports generated for project managers may contain aggregated results with less detail on the specific issues. EARL does not require these assertions to be in a single file, database, or other form of repository; RDF parsers should be able to work with distributed information provided they have access.

A valid EARL report must validate against the formal RDF grammar, and must adhere to the constraints defined by this document. In case of discrepancy, the normative reference is Appendix A: EARL 1.0 Schema in RDF/XML. Note: to support XML based applications, EARL reports should be represented in (a compact) RDF/XML format when being exported or published outside an application. However, EARL processors should be able to parse valid reports in other RDF formats such as N3.

If the core EARL vocabulary is extended for specific purposes (for example by subclassing terms), the RDFS (including relevant OWL constraints etc.) must be provided so that RDF parsers can process the introduced vocabulary correctly. Furthermore, any extensions must ensure the integrity and validity of the core EARL vocabulary in order to ensure interoperable exchange of EARL reports.

Appendix A: EARL 1.0 Schema in RDF/XML

<?xml version="1.0" encoding='UTF-8'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

  <rdf:Description rdf:about="http://www.w3.org/ns/earl#">
    <rdfs:label xml:lang="en">EARL 1.0 Schema</rdfs:label>
    <rdfs:comment xml:lang="en">Evaluation And Report Language (EARL) 1.0 Schema as defined by http://www.w3.org/TR/EARL10-Schema/</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#Assertion">
    <rdfs:label xml:lang="en">An assertion</rdfs:label>
    <rdfs:comment xml:lang="en">Parent node that contains all parts of an assertion</rdfs:comment>
    <rdfs:subClassOf rdf:parseType="Collection">
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#assertedBy"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>
        <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality>
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#subject"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>
        <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality>
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#test"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>
        <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality>
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#result"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>
        <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality>
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#mode"/>
        <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality>

  <rdf:Property rdf:about="http://www.w3.org/ns/earl#assertedBy">
    <rdfs:label xml:lang="en">Is Asserted By</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Assertion"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#Assertor"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#subject">
    <rdfs:label xml:lang="en">Has Test Subject</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Assertion"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#TestSubject"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#test">
    <rdfs:label xml:lang="en">Has Test Criterion</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Assertion"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#TestCriterion"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#result">
    <rdfs:label xml:lang="en">Has Test Result</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Assertion"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#TestResult"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#mode">
    <rdfs:label xml:lang="en">Has Test Mode</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Assertion"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#TestMode"/>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#Assertor">
    <rdfs:label xml:lang="en">Assertor</rdfs:label>
    <rdfs:comment xml:lang="en">Persons or evaluation tools that claim assertions</rdfs:comment>
    <owl:oneOf rdf:parseType="Collection">
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#SingleAssertor"/>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#CompoundAssertor"/>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#SingleAssertor">
    <rdfs:label xml:lang="en">Single Assertor</rdfs:label>
    <rdfs:comment xml:lang="en">One person or evaluation tool that claims assertions</rdfs:comment>
    <owl:oneOf rdf:parseType="Collection">
      <owl:Thing rdf:type="http://www.w3.org/ns/earl#Software"/>
      <owl:Thing rdf:type="http://xmlns.com/foaf/0.1/Agent"/>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#CompoundAssertor">
    <rdfs:label xml:lang="en">Compound Assertor</rdfs:label>
    <rdfs:comment xml:lang="en">Group of persons or evaluation tools that claim assertions</rdfs:comment>
    <rdfs:subClassOf rdf:parseType="Collection">
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#mainAssertor"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>

  <rdf:Property rdf:about="http://www.w3.org/ns/earl#mainAssertor">
    <rdfs:label xml:lang="en">Has Main Assertor</rdfs:label>
    <rdfs:comment xml:lang="en">Assertor mainly responsible for determining assertion result</rdfs:comment>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#CompoundAssertor"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#Assertor"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#helpAssertor">
    <rdfs:label xml:lang="en">Has Help Assertor</rdfs:label>
    <rdfs:comment xml:lang="en">Assertor assisting to determine assertion result</rdfs:comment>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#CompoundAssertor"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#Assertor"/>
  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#TestSubject">
    <rdfs:label xml:lang="en">Test Subject</rdfs:label>
    <rdfs:comment xml:lang="en">Subject of the assertion</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#TestCriterion">
    <rdfs:label xml:lang="en">Test Criterion</rdfs:label>
    <rdfs:comment xml:lang="en">A testable statement against which subjects are tested</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#TestRequirement">
    <rdfs:subClassOf rdf:resource="http://www.w3.org/ns/earl#TestCriterion"/>
    <rdfs:label xml:lang="en">Test Requirement</rdfs:label>
    <rdfs:comment xml:lang="en">A requirement against which subjects are tested</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#TestCase">
    <rdfs:subClassOf rdf:resource="http://www.w3.org/ns/earl#TestCriterion"/>
    <rdfs:label xml:lang="en">Test Case</rdfs:label>
    <rdfs:comment xml:lang="en">A test case against which subjects are tested</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#TestMode">
    <rdfs:label xml:lang="en">Test Mode</rdfs:label>
    <rdfs:comment xml:lang="en">Mode in which tests were conducted</rdfs:comment>
    <owl:oneOf rdf:parseType="Collection">
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#manual">
        <rdfs:label xml:lang="en">Manual</rdfs:label>
        <rdfs:comment xml:lang="en">Test was performed by a human only</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#automatic">
        <rdfs:label xml:lang="en">Automatic</rdfs:label>
        <rdfs:comment xml:lang="en">Test was performed by a tool only</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#semiAutomatic">
        <rdfs:label xml:lang="en">Semi-Automatic</rdfs:label>
        <rdfs:comment xml:lang="en">Test was performed primarily by a tool, and human assistance</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#notAvailable">
        <rdfs:label xml:lang="en">Not Available</rdfs:label>
        <rdfs:comment xml:lang="en">Test was performed by a combination of persons and tools</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#heuristic">
        <rdfs:label xml:lang="en">Heuristic</rdfs:label>
        <rdfs:comment xml:lang="en">Result was derived from other results</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#TestResult">
    <rdfs:label xml:lang="en">Test Result</rdfs:label>
    <rdfs:comment xml:lang="en">Result from conducting test cases on subjects</rdfs:comment>
    <rdfs:subClassOf rdf:parseType="Collection">
        <owl:onProperty rdf:resource="http://www.w3.org/ns/earl#outcome"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>
        <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality>

  <rdf:Property rdf:about="http://www.w3.org/ns/earl#outcome">
    <rdfs:label xml:lang="en">Has Outcome</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#TestResult"/>
    <rdfs:range rdf:resource="http://www.w3.org/ns/earl#OutcomeValue"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#pointer">
    <rdfs:label xml:lang="en">Has Location Pointer</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#TestResult"/>
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#info">
    <rdfs:label xml:lang="en">Has Additional Information</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#TestResult"/>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#OutcomeValue">
    <rdfs:label xml:lang="en">Outcome Value</rdfs:label>
    <rdfs:comment xml:lang="en">Nominal value of the result</rdfs:comment>
    <owl:oneOf rdf:parseType="Collection">
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#pass">
        <rdfs:label xml:lang="en">Pass</rdfs:label>
        <rdfs:comment xml:lang="en">Test passed</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#fail">
        <rdfs:label xml:lang="en">Fail</rdfs:label>
        <rdfs:comment xml:lang="en">Test failed</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#cannotTell">
        <rdfs:label xml:lang="en">Can Not Tell</rdfs:label>
        <rdfs:comment xml:lang="en">Outcome of the test is uncertain</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#notApplicable">
        <rdfs:label xml:lang="en">Not Applicable</rdfs:label>
        <rdfs:comment xml:lang="en">Test is not applicable to the subject</rdfs:comment>
      <owl:Thing rdf:about="http://www.w3.org/ns/earl#notTested">
        <rdfs:label xml:lang="en">Not Tested</rdfs:label>
        <rdfs:comment xml:lang="en">Test has not been carried out</rdfs:comment>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#Software">
    <rdfs:label xml:lang="en">Software Tool</rdfs:label>
    <rdfs:comment xml:lang="en">A tool that can perform tests or be the subject of testing</rdfs:comment>
    <rdfs:subClassOf rdf:parseType="Collection">
        <owl:onProperty rdf:resource="http://purl.org/dc/elements/1.1/title"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>

  <rdfs:Class rdf:about="http://www.w3.org/ns/earl#Content">
    <rdfs:label xml:lang="en">Content</rdfs:label>
    <rdfs:comment xml:lang="en">Subjects that are available on the Web</rdfs:comment>
    <rdfs:subClassOf rdf:parseType="Collection">
        <owl:onProperty rdf:resource="http://purl.org/dc/elements/1.1/date"/>
        <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:minCardinality>

  <rdf:Property rdf:about="http://www.w3.org/ns/earl#sourceCopy">
    <rdfs:label xml:lang="en">Has Copy of Source</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Content"/> 
  <rdf:Property rdf:about="http://www.w3.org/ns/earl#context">
    <rdfs:label xml:lang="en">Has Context</rdfs:label>
    <rdfs:domain rdf:resource="http://www.w3.org/ns/earl#Content"/> 


Appendix B: EARL 1.0 Terms (Non-Normative)

The following terms are defined by this specification:


Classes in the EARL namespace
Class Name Label Allowable types Suggested types required properties recommended properties optional properties
earl:Assertion Assertion     earl:mode  
earl:Assertor Assertor        
earl:SingleAssertor Single Assertor      
earl:CompoundAssertor Compound Assertor     earl:mainAssertor  
earl:TestSubject Test Subject      
  • dc:title
  • dc:description
  • dc:date
  • dct:hasPart
  • dct:isPartOf
earl:TestCriterion Test Criterion      
  • dc:title
  • dc:description
  • dct:hasPart
  • dct:isPartOf
earl:TestRequirement Test Requirement        
  • dc:title
  • dc:description
  • dct:hasPart
  • dct:isPartOf
earl:TestCase Test Case        
  • dc:title
  • dc:description
  • dct:hasPart
  • dct:isPartOf
earl:TestMode Test mode        
earl:TestResult Test Result     earl:outcome
  • dc:title
  • dc:description
earl:OutcomeValue Outcome Value        
earl:Software Software Tool       dc:title
  • dct:hasVersion
  • dc:description
  • foaf:homepage
earl:Content Content        


Properties in the EARL namespace
Property Name Label Domain Range Restriction
earl:assertedBy Is Asserted By earl:Assertion earl:Assertor Exactly one per earl:Assertion
earl:subject Has Test Subject earl:Assertion earl:TestSubject Exactly one per earl:Assertion
earl:test Has Test Criterion earl:Assertion earl:TestCriterion Exactly one per earl:Assertion
earl:result Has Test Result earl:Assertion earl:TestResult Exactly one per earl:Assertion
earl:mode Has Test Mode earl:Assertion earl:TestMode At most one per earl:Assertion
earl:mainAssertor Has Main Assertor earl:CompoundAssertor earl:Assertor At least one per earl:CompoundAssertor
earl:helpAssertor Has Help Assertor earl:CompoundAssertor earl:Assertor  
earl:outcome Has Outcome earl:TestResult earl:OutcomeValue Exactly one per earl:TestResult
earl:info Has Additional Information earl:TestResult   Recommended to use Literal values
earl:pointer Has Location Pointer earl:TestResult   Recommended to use Pointer Methods in RDF [Pointers]
earl:sourceCopy Has Copy of Source earl:Content   Recmmended to use HTTP Vocabulary in RDF [HTTP]
earl:context Has Context earl:Content   Recmmended to use HTTP Vocabulary in RDF [HTTP]


Values in the EARL namespace
Value Name Label Used In Description
earl:manual Manual earl:TestMode Test was performed based on a person's judgement
earl:automatic Automatic earl:TestMode Software tool has carried out the test automatically without any human intervention
earl:semiAutomatic Semi-Automatic earl:TestMode Software tool was primarily responsible for generating a result, even if with some human assistance
earl:notAvailable Not Available earl:TestMode Unidentified combination of persons and software tools was used to carry out the test
earl:heuristic Heuristic earl:TestMode Assertion was made by inference, for example based on several existing test results
earl:pass Pass earl:OutcomeValue An assertor claims a test passed successfully
earl:fail Fail earl:OutcomeValue The Test Subject did not meet the Test Criterion
earl:notTested Not tested earl:OutcomeValue An Assertor can not tell for sure what the outcome of the test is
earl:cannotTell Cannot tell earl:OutcomeValue The Test Criterion is not applicable to the given Test Subject
earl:notApplicable Not Applicable earl:OutcomeValue Test has not been carried out

Appendix C: Document Changes (Non-Normative)

The following is a list of changes since the 27 September, 2006 Working Draft:

Appendix D: References (Non-Normative)

The Dublin Core Metadata Element Set - DC Recommendation, 20 December 2004.
The Dublin Core Metadata Terms - DC Recommendation, 13 June 2005.
FOAF Vocabulary Specification - Working Draft, 3 June 2005.
Evaluation and Report Language (EARL) 1.0 Guide - Editors' Draft 14 December 2005. C. Velasco, J. Koch, S. Abou-Zahra eds.
HTTP Vocabulary in RDF - W3C Working Draft 20 December 2006. J. Koch, C. Velasco, S. Abou-Zahra eds.
OWL Web Ontology Language - W3C Recommendation, 10 February 2004.
Pointer Methods in RDF - Editors' Draft 22 February 2007. J. Ley eds.
RDF/XML Syntax Specification (Revised) - W3C Recommendation, 10 February 2004. D. Beckett ed.
RDF Primer - W3C Recommendation, 10 February 2004. F. Manola, E.Miller eds.
RDF Vocabulary Description Language 1.0: RDF Schema - W3C Recommendation, 10 February 2004. D. Brickley, R.V. Guha eds.
Why RDF model is different from the XML model - Paper, September 1998. T. Berners-Lee.
Key words for use in RFCs to Indicate Requirement Levels - IETF RFC, March 1997.
Web Content Accessibility Guidelines 1.0 - W3C Recommendation, 5 May 1999. W. Chisholm, I. Jacobs, G. Vanderheiden eds.
XML Schema Part 0: Primer Second Edition - W3C Recommendation, 28 October 2004. D. Fallside, P. Walmsley erds.

Appendix E: Contributors (Non-Normative)

EARL is the result of the work of many people over the past. The editors would particularly like to thank Wendy Chisholm, Sean B Palmer, and Daniel Dardailler, whose contributions have included editing the first versions of the EARL specifications, and the late Leonard Kasday who set the work in motion to develop EARL. The editors apologise for any names left out of this list, and will endeavour to rectify any errors noted in comments.

Contributors to this and/or previous Working Drafts

Shadi Abou-Zahra, Chrisoula Alexandraki, Shane Anderson, Myriam Arrue, Gabriele Bartolini, Giorgio Brajnik, Dan Brickley, Dan Connolly, Karl Dubost, Nick Gibbins, Al Gilman, Dominique Hazaël-Massieux, Nadia Heninger, Sandor Herramhof, Ian Hickson, Björn Höhrmann, Carlos Iglesias, Nick Kew, Johannes Koch, Jim Ley, William Loughborough, John Lutts, Charles McCathieNevile, Libby Miller, Tom Martin, Yehya Mohamed, Daniela Ortner, Dave Pawson, Eric Prud'hommeaux, Pierre Queinnec, Chris Ridpath, Romain Roure, Christophe Strobbe, Aaron Swartz, Olivier Thoreaux, Carlos Velasco and Rob Yonaitis.