W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > October 2001

EARL 1.0 Notebook

From: Sean B. Palmer <sean@mysterylights.com>
Date: Tue, 9 Oct 2001 02:39:54 +0100
Message-ID: <01bb01c15063$6a6569a0$55d993c3@y0r1d9>
To: <w3c-wai-er-ig@w3.org>
[Some notes on EARL 1.0; mainly for myself, but please review.]

This is following on from "EARL 1.0" - [1]; a kind of standard guide to
creating EARL 1.0. I proposed (as a 0.95 <=> 1.0 intermediary transition):-

   evaluation =
      assertor asserts assertion .
   assertor context_properties information .
   assertion assertion_properties information .

Now, do we want to use grounded triples, or litter them with existentials?
Can we force people to do either? I think not: we'll let implementors
decide, because the tools should grok them basically the same (for the
purposes of "what EARL does" anyway).

I'd rather do something of the order of:-

   earl:Evaluation rdfs:subClassOf rdf:Statement .
   earl:assertedBy rdfs:domain earl:Evaluation .

and scrap earl:asserts. Would that increase the triples too much?

   :Sean earl:asserts _:x .
   :Sean :name "Sean" .
   _:x rdf:subject :s .
   _:x rdf:predicate :p .
   _:x rdf:object :o .


   _:y earl:subject :s .
   _:y earl:validity :p .
   _:y earl:evaluationObject :o .
   _:y earl:assertedBy :Sean .
   :Sean :name "Sean" .

Same amount of triples... it's more unweildy in abbreviated syntax, though.
And can XML RDF handle it? Just about; if :Sean were _:Sean it may be a
different matter. Actually, it would force people to ground the assertor,
so perhaps it would be a good thing :-)

The reification refinement is a cool hack, but I'll bet I get shouted at
for it:-

   earl:subject rdfs:subPropertyOf rdf:subject .
   earl:validity rdfs:subPropertyOf rdf:predicate .
   earl:evaluationObject rdfs:subPropertyOf rdf:object .

And the point of that is? Well, it's more specific, and it nearly hides the
fact that we're reifying stuff. It just seems more friendly. But is it
worth changing the structure of the language? Well, if we're going to
change EARL at all, we may as well change it properly.

As for test subjects... they're bNodes, and they can stay that way.
However, I did think it would be neat to identify new resopurces by line
number and possibly column:-

   _:a earl:testSubject <http://example.org/> .
   _:a earl:line "10" .

and possibly even RegExps! Whee! When you can't tack it onto the end of a
URI as a FragID, just use an RDF property :-)

A union of date and version should be required, where Version is
subclassable, and where we should be thinking about avoiding all the junk
about datatyping that has been flying about.

Customizable validity properties should be taken out, and we can just
declare a few. We can always bung "certainty" as an arc coming off of the
evaluation, and give it the semantics that it applies to the certainty of
the evaluation, and not any of the tangents coming off it it. I suppose
that's a given.

Test cases are a bit messy too. The exclusion thing is cool, but is it too
powerful? Dunno about that. earl:label [2] would be cool, to label the test


[1] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Jul/0029
[2] earl:label rdfs:subPropertyOf rdfs:label .

Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Monday, 8 October 2001 21:41:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:33 UTC