This should be considered a normative reference guide to the EARL 0.95 schema, made available by the W3C WAI ER WG.
The EARL schema was developed with the data model and vocabulary in mind, but, as ever, there were some problems in expressing semantics - due in part to a lack of terms in the Semantic Web, and due also to some bugs in the RDF specification.
The first thing to note is the way in which the higher-order statements
are constrained in the schema - as a restriction on the reification properties.
This does not mean that EARL can only be expressed using reified
statements per the RDF 1.0 specification - use whatever system is most
convenient in your own particular syntax, as long as it follows the EARL model,
which is Evaluation=(Assertor asserts Assertion) Assertion=(TestSubject
ResultProperty Testcase). Evaluations don't have to be reified: if the
three parts of an Evaluation are used, then the triple is automatically an
earl:Evaluation - try the EARL 0.95 schema for more
details (XML RDF, N3).
The EARL schema also has three satellite files, one for the datatypes, one for inferences, and (linked form the inferences file) one for a 0.9 to 0.95 conversion. Those three files are persistently maintained at the following respective URIs:-
http://www.w3.org/2001/03/earl/0.95datatypeshttp://www.w3.org/2001/03/earl/0.95inferenceshttp://www.w3.org/2001/03/earl/0.9to0.95The namespace for the EARL 0.95 datatypes is:-
http://www.w3.org/2001/03/earl/0.95datatypes#
Inference languages on the Semantic Web have to be recognized uniformly by processors, but as there are few tools for either the languages or the processing at this stage, we have simply pointed to the files with rdfs:seeAlso arcs. This is fine, because at this stage all of the inferencing will have to be set up by a human. When tools and vocabularies become available, we may change the schemata to reflect that.
To give an assertion an ID, we suggest that you declare it as being equivalent to a particular URI, for example by using daml:equivalentTo.
Note the following:-
{ earl:TestSubject daml:disjointFrom earl:Assertor } a log:Falsehood .
It may at first seem strange to enable a TestSubject to also be an Assertor, but note the use-case of a Tool wanting to evaluate itself, or one tool evaluating another tool in the same file.
Some classes in EARL ar pair-wise disjoint, but these have not been stated for two reasons - 1) its often common sense, and 2) we don't want to constrain the language and then find later that we've constrained it too much. There are some declations of classes being disjoint in the schema where the case is not so clear cut - for example, the sub classes of TestSubject, and the Suite and Id classes, etc.
EARL 0.95 introduces a new property - earl:sameSubjectAs - to mark two pieces of content as being somehow similar. The exact semantics of the similarity are not stated in the schema because any such mechanism would have to be very finely grained to be of any explicit use. Hence, this property is probably only useful on a basic level, to track content as it is moved about a site, rather than to state complex relationships of content according to context.
An example use of this property is:-
:Sean earl:asserts { :MyParagraph :fails :Blargh .
:MySameParagraph :passes :Blargh } .
:MyParagraph a earl:TestSubject;
earl:date "2001-01-01" .
:MySameParagraph a earl:TestSubject;
earl:date "2001-01-02";
earl:sameSubjectAs :MyParagraph .
EARL 0.95 introduces two properties: testSuite and testId that can be used wherever they are required. earl095:testSuite is equivalent to earl9:suite. Be careful not to confuse this with earl:suite. They are defined in EARL 0.95 as:-
Note that although DAML is used extensively in the schema, there is no particular need to use it in any of the instances, although we don't stop you from doing so. If you need it, use it.
As an example of creating your own earl:ResultProperty, let's say that you want to make an assertion that your page passes a certain checkpoint with a medium degree of confidence. To do that, you would have to create a new earl:ResultProperty, with an earl:validity arc pointing to earl:Pass, and an earl:confidence arc pointing to earl:Medium. viz.:-
:MyNewProperty a earl:ResultProperty; earl:validity earl:Pass; earl:confidence earl:Medium .
Note also that when you create a new property, you have to give it a name (this could be automatically generated), and put it in your own namespace. Do not under any circumstances invent new properties in the EARL namespace that don't exist. cf. EARL 0.95 Architecture:-
A note on generating IDs for EARL output: in EARL, you must often give labels (IDs) to each part of the evaluation and assertions, so as they can be reused in the future. These IDs *must* be unique, and not conflict with anything else. They should not have secondary uses. All EARL IDs are simply URIs within arbitrary namespaces, as created by the EARL evaluation processor. In other words, they are GenIDs (generated IDs). RDF syntax may in future address methods of specifying bases for GenIDs, but no guarantee is made.
From EARL 0.95 Architecture again:-
The next issue on the list is the representation of non-XML languages that have a BNF. The only way to do this (that I can think of) is the traditional EARL way of creating a new date-stamped resource, declaring that it's an XML representation of the BNF of the original resource, and then using an XPointer (somehow!) on that. This begs the question - can you use XPointers on conceptual resources? Does that qualify as one of the greatest hacks ever conducted on a Web development list?
Although not stated in the schema (is it impossible?), the value of earl:toDate must obviously be later that that of earl:fromDate, and the two dates are inclusive.
Comments to w3c-wai-er-ig@w3.org [archives] please.
Sean B. Palmer, $Id: 0.95notes.html,v 1.3 2001/12/29 03:39:00 spalmer Exp $