# Re: Requirement? An "evidence" property

Date: Tue, 22 Mar 2005 11:40:02 +0100
To: "'Charles McCathieNevile'" <charles@sidar.org>
Cc: <public-wai-ert@w3.org>
Message-ID: <009901c52ecb\$812372f0\$6466a8c0@K2>
```
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,

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:52 UTC