Re: Requirement? An "evidence" property

Hi,

I totally agree that we need to support some sort of aggregation into EARL. For example, let's take Karl's famous sunday-theorem:

---
Story: I'm going out only if the temperature is +25°C, it's sunny, and 
it's sunday.

Question:
 Assertion: Do you go out? <URI_assertion>
  Test 1: if T > 25 -> yes, if T < 25 -> no
  Test 2: if W = sun -> yes, if W = rain -> no
  Test 3: if D = sunday -> yes, if D = Monday, ..., Saturday -> no
 
 Report: (EARL)
  Assertion yes, no, comment
---

We make the assertion on the "going out" level but it would be good if we could have some way to reason our claim.

However, I'm not entirely convinced it should be in something like the evidence structure you are proposing but rather within the Subject which we are testing. What I mean is some way to say the result is for one atomic test (i.e. "Test 2") or for a statement ("go out on sunday") which is actually an aggregation of tests (Tests 1+2+3).

What do others think?

Regards,
  Shadi



-----Original Message-----
From: public-wai-ert-request@w3.org On Behalf Of Charles McCathieNevile
Sent: Monday, March 21, 2005 00:57
To: public-wai-ert@w3.org
Subject: Requirement? An "evidence" property



Particularly in dealing with results that are inferred from other results,  
one of the things I have wanted is some way of saying how those results  
were derived.

This may be a particular extension to earl:message (i.e. modelled as an RD  
subProperty). That would require the range of a Message to be pretty  
unconstrained.

The simple use case I have is as follows:

I use MUTAT to generate assertions that the EARL spec meets each of the  
required tests in SpecGL. I also write an OWL rule that says that anything  
that meets each test meets the test "conforms to SpecGL".

I want to generate an assertion that says the EARL spec conforms to  
SpecGL, and provide linkage to why I think this is so. That way, I can  
ship around the single assertion, but people can follow it back and verify.

The design I have in mind looks like this:

<Assertion>
   <assertedBy r:resource="#chaals" />
   <testCase r:resource="../../SpecGL#required" />
   <result r:type="&earl;pass" />
   <mode r:resource="&earl;heuristic" />

<!-- the foregoing is already there. The following is what I suggest as a  
strawman -->

   <evidence r:parseType="Collection">
     <evRule r:resource="../../SpecGL#requiredRule" />
     <Assertion r:resource="#point1A" />
     <Assertion r:resource="#point1B" />
     <Assertion r:resource="#point2A" />
     <Assertion r:resource="#point3A" />
     <Assertion r:resource="#point3B" />
     <Assertion r:resource="#point3C" />
     <Assertion r:resource="#point4A" />
     <Assertion r:resource="#point5A" />
     <Assertion r:resource="#point5B" />
     <Assertion r:resource="#point6A" />
   </evidence>
...

Things that come up immediately:

Querying a collection is a pain at the moment. EricP promised, in the  
meeting in Boston, that there was a way around it, but suggested that a  
standardised way around it won't get into SPARQL until version 2, which  
they expect to be 18 months - 2 years away. (Their predictions, on the  
other hand, seem relatively well-grounded so far, so I am not afraid that  
it will really be 6 years away although that possibility should not be  
ignored).

It is important to have a collection, IMHO. As I understand it this is  
about the only RDF mechanism to say "these things an nothing else", which  
avoids problems when people start merging data, or modelling complex data.

This covers providing evidence for a simple deduction. We should try to  
anticipate this being used to provide evidence relied on by other tests,  
too. Which I suspect means in particular that we should not rush to  
restrict the scope, even if we do not want to get into designing a test  
description language yet...

I also have a more complex use case, which I will send seperately.

cheers

Chaals

-- 
Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org

Received on Tuesday, 22 March 2005 10:40:03 UTC