Formalizing testSubject

In EARL, the TestSubject is the thing being evaluated. There are two
requirements for identifying test subjects in EARL: a) we must be able
to refer to anything, and b) we must be very clear about what is being
identified. Examples of things that we may want to evaluate in EARL
are:-

   * A web page http://example.org/ on a particular date
   * A part of a web page - just an element, or a few elements
   * An accessibility tool, or a User Agent

This much we already know. In EARL 0.95, sometimes we have a necessary
level of indirection. For example, if you want to point to the page
http://example.org/ as it was on 2002-03-02, you can't just do
something like:-

   <http://example.org/> earl:fails :SomeTest; earl:date "2002-03-02"
.

because you'll lose the date information on merging. So instead, we
create a new thing - bNoded, or with a URI - something like [
earl:testSubject <http://example.org/>; earl:date "2002-03-02" ] .
This can be read as "a thing which is the web content at
http://example.org/ on the date 2002-03-02". In fact, there is some
information left out there. We don't really know that we're evaluating
a bit of WebContent at all...

   [ a earl:WebContent; earl:date "2002-03-02";
      earl:testSubject <http://example.org/tool> ] .
   [ a earl:Tool; earl:date "2002-03-02";
      earl:testSubject <http://example.org/tool> ] .

In this case, it's clear(er) what's being evaluated. In the top
example, we're evaluating the documentation for the tool, and in the
bottom example we're evaluating the tool documented at
http://example.org/tool. Unfortunately, there's no way that we can
either a) force people to use a type arc, or b) deduce what the author
of the URI *means* by it, unless they have stated that at the resource
itself.

So there's a problem there - ambiguity. I previously resolved [1] to
clear this up by introducing two new properties that would take the
place of testSubject: earl:reprOf, and earl:documentation. For example
(now assuming an EARL 1.0 namespace):-

   [ earl:reprOf <http://example.org>; earl:date "2002-03-02" ] .
   [ earl:documentation <http://example.org>; earl:date "2002-03-02" ]
.

rdf:type arcs aren't strictly necessary here since we know that the
domain of earl:reprOf is earl:WebContent, and that the domain of
earl:documentation is a union of earl:Tool and earl:UserAgent.

But it isn't necessary that we deprecate testSubject if people want to
include it; we can rely on people using rdf:type to tell us the kind
of content (as we do in EARL 0.95). A schema snippet for this is at
[2].

So there's a choice for EARL 1.0:-

   a) Use testSubject and not reprOf/documentation.
   b) Let people choose: testSubject or reprOf/documentation
   c) Use reprOf/documentation and not testSubject

Option a will depend upon people including an rdf:type arc, option b
may do if they choose to use testSubject, and the latter option will
not rely on rdf:type at all since the domains will take care of it.

There are also some issues about identifying bits of representations
etc., but that's not strictly a part of this debate, IMO.

Cheers,

[1] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Dec/0018
[2] earl:TestSubject rdfs:subClassOf
        [ daml:onProperty earl:testSubject; daml:cardinality "1" ] .
   earl:reprOf rdfs:subPropertyOf earl:testSubject .
   earl:documentation rdfs:subProperty earl:testSubject .

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Saturday, 2 March 2002 18:34:43 UTC