Re: On ISSUE-26 : RDFa Error vocabulary

Hi Mark,

I am sorry but... I continue not to be convinced of taking over the 'test related' terms for RDFa. All the EARL extracts you refer to really speak about testing and validation and forcing our scenario into that set of concepts is pushing things in my view. Even your example referring to the extension possibilities refers to _validation_ which is not what we are talking about. And... just imagine how our users (who do not really understand and do not want to understand EARL and its details and goals) would react if they see terms like TestResults for an error resulting from a network glitch! I am not sure how I would explain that myself. 

I also realized that what I proposed via EARL is, strictly speaking, incorrect. Indeed, the EARL specification puts a number of restrictions on the usage of an assertion class, it _requires_ the presence of attributes like earl:result, ie, attributes whose usage I am not comfortable with at all. Ie, I have to retract what I proposed yesterday:-(

Mark, we may have to agree to disagree on that point and see what the rest of the Working Group decides:-(

For a more complete documentation for the group, I have kept, on [1], the proposal of yesterday, even added some other features and explanations. As a comparison, I have also put onto [1] a simple alternative which is close to the proposal which started the discussion a few days ago, although I did take over some feature that came up during the discussion that is better nevertheless (eg, usage of dc for a number of things) (which also led to the removal of the 'onURI' property for the slightly more general 'context').

Ivan

[1] http://www.w3.org/2010/02/rdfa/wiki/Error_vocabulary

On Jul 2, 2010, at 24:20 , Mark Birbeck wrote:

> 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)


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf