Re: On ISSUE-26 : RDFa Error vocabulary

Hi Ivan,

> So... (just in time for the telco)

After all your hard work, I'm sorry that I had to miss the call at the
last minute.


> First of all, I looked at the Earl and related documentation again, and then had a chat
> with Shadi Abu-Zahra, who is the staff contact in the relevant group and also co-editor
> of EARL.

Great...thanks for doing that.


> First of all, EARL is in second last call. This means that while it is possible to have some
> editorial changes in the document, he does not think it is possible to make substantial
> changes, eg, changing attribute and class names.

Right, and I definitely wasn't expecting them to do that. I saw this
as a longer term thing, where we could perhaps add a few terms that
help us, with a view to eventually folding them back into EARL.


> Then we went through the issues and we agreed that some classes (eg, assertor, assertion)
> could be used for error handling purposes while slightly changing the text description of those
> classes (it currently says, for Assertion "a statement that embodies the results of a test."

Great.


> But we also agreed that the term 'test' does not really apply for what we do in RDFa and,
> unfortunately, the terms used for most of the properties and classes do refer to tests all
> over the place. Not only the class and property names often refer to tests (TestResult,
> TestSubject, test,...) but the properties have range and domain definition that often refer
> to these classes, ie, by using them, we would assert certain classes to be, say, Test
> results, when in reality they aren't.

Mmm...far be it for me to disagree with one of the specification's
editors about his own specification...

...but...

1. They don't actually define what a test is. They define the
relationship between tests, testers, criteria, software, and so on,
but they don't actually say what a test is. The closest they get is in
the overview [1]:

  This structure shows the universal applicability of EARL and its
ability to refer to any type
  of test: bug reports, software unit tests, test suite evaluations,
conformance claims, or
  even tests outside the world of software and the World Wide Web
(although in such cases,
  there may be issues regarding its full applicability).


2. Ok, you might come back at me by saying that although they don't
define a test, we all know what one is. The problem with that line of
reasoning is that the various documents that make up EARL are littered
with references to things and scenarios that are /not/ what you would
normally call a test.

For example, they talk of checking XHTML documents according to
accessibility guidelines. This is not 'testing' in any sense that a
software developer would recognise it, but is instead validation or
conformance checking. One of their illustrations looks at some
fictitious software and how it behaves when checking the conformance
of attributes on <img> tags in an XHTML document -- they are not
'testing' software but 'validating' a document.

And I actually like this looseness; I don't think they should change
it, and I also don't think they need to add much of anything to allow
us to base our validation on EARL. It's this very looseness that in my
mind allows us to create 'validation' or 'conformance', and the only
thing I would do would be to put something right at the top of the
specifications (or in the overview documents) that says that a 'test'
is nothing more than 'an assertion that can pass or fail'.


3. The opening paragraph of the abstract in the EARL guide [1] ends with this:

  [EARL] also provides reusable terms for generic quality assurance
and validation purposes.

The same document concludes with:

  This guide presented a thorough overview of the Evaluation and
Report Language (EARL).
  As mentioned in the introduction, EARL must be seen as a generic
vocabulary that can
  facilitate the creation and exchange of test reports. In this
generality lies its strength, as
  it can be applied to multiple scenarios and use cases, which may
even lay outside the
  world of software development and compliance testing.

  EARL also allows merging and aggregation of results in a semantic
manner, thus enabling
  different testing actors to share and improve results.

  Of course, there could be scenarios where EARL might not be able to
cope with their
  underlying complexity. However, its semantic nature allows its
extensibility via new
  vocabularies based upon RDF, without endangering the
interoperability of the reports.

It seems to me that extensibility and general-purposefulness are right
at the heart of EARL, and that our scenario would be exactly the kind
of thing that they would want to be able to handle.


4. I've only just spotted this...they use the example of an XML
validator in section 4 of the EARL Guide [2]!

They discuss validating data as part of a SOAP request, and of using
EARL as a way to create more useful reports for the users of the web
service. They even discuss creating error and warning classes by
deriving them from the EARL classes.

I think that's the clincher, to be honest, and I think given all of
these factors together we are perfectly entitled to base our classes
on the EARL classes.


> What I did is to go again through all these documents and changed what we have. It is on the
> wiki, to make it quicker, it is reproduced here (also using some of Mark's example):

Great...once again, thanks for taking the trouble to look at this.


> <#assertor> a earl:Assertor, earl:Software, foaf:Agent ;
>   foaf:name "RDFa Distiller" ;
>   dc:description "RDFa Distiller Service" ;
>   foaf:homepage <http://www.w3.org/2007/08/pyRdfa/> ;
>   dc:hasVersion "2.3.5" .

Nice. I didn't add the extra types just in case they became a
distraction, but I like the fact that you are working up a 'fuller'
example here.


> [] a earl:Assertion ;
>   earl:assertedBy <#assertor> ;
>   rdfa:subject <http://www.example.org> ;
>   rdfa:error [

As discussed above I don't think we need to create an of our own things here.


>       a rdfa:ProfileReferenceError ;
>       dc:description "The @profile value could not be deferenced" ;
>       dc:date "2010-06-30T13:40"^^xsd:dateTime ;
>       rdfa:onUri <http://www.example.org/profile> ;

Even if we don't use EARL, I think this could do with rethinking,
because there must be something, somewhere that we can build on.


>       rdfa:pointer [
>           ptr:reference <http://www.example.org> ;
>           # if exact pointer information can be provided here...
>       ]
>   ] .
>
> I used the pointer from Mark's example, though I am not sure this could be
> universally used. Eg, my distiller runs a DOM parser on the source, so the
> line and character number is completely lost by the time error is managed.

The 'ptr' bit comes from EARL, or rather EARL in makes use of
'Pointers in RDF' [3].

This WD supports XPath, CSS and XPointer as well. So I'd imagine that
Distiller would report results using XPath, and an XPath example from
the spec looks like this:

  <ptr:XPathPointer rdf:about="#xPathPointer">
    <ptr:version>2.0</ptr:version>
    <ptr:expression>/html/body/div[@id='header']/img[1]</ptr:expression>
    <ptr:reference rdf:resource="http://example.org/doc1.html"/>
    <ptr:namespace rdf:resource="#NamespaceMapping1"/>
  </ptr:XPathPointer>


> The rdfa specific properties are needed to replace their earl equivalents but without a
> range/domain specification; here is the schema:
>
> [...]

Hopefully we see now that this is not necessary.


> B.t.w., I agreed with Shadi that he would look at the RDFa vocabulary when we think it
> is closer to final.

I think that extra sentence about a test being nothing more than an
assertion is all we need to allow EARL to be usable unchanged.

Once again, thanks for taking the trouble to look into this Ivan.

Regards,

Mark

[1] <http://www.w3.org/TR/EARL10-Guide/>
[2] <http://www.w3.org/TR/EARL10-Guide/#advanced>
[3] <http://www.w3.org/TR/Pointers-in-RDF10/>

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 1 July 2010 22:21:17 UTC