Re: Questions and proposals related to strawman schema from F2F

Charles McCathieNevile <charles@w3.org> writes:

> toolX claims resourceY passes tests T1 and T2, and claims that
> therefore resourceY passes criterionA

> personX claims resourceY passes test T4 but fails test T3, and
> therefore fails criterionA (without testing T1 or T2).

> ToolZ claims that since resourceY passes test T1 and T4 (based on
> claims by other assertors), resourceY passes criterionB

> Then we don't have to worry at what level the tests and criteria are
> - we can mix "double-A WCAG conformance" and "content of the alt
> attribute ends with the string '.gif'" easily.

Does this mean that we can view a criterion can be viewed as a group
of testcases?

> This is in fact useful - if we want to test WCAG level A and Section
> 508 then we can do it by mixing the claim level-A with a few
> checkpoints from elsewhere in WCAG.

ie. overlapping groups of testcases

> Of course it requires that we can express the fact that

> <earl:passes>
>   <rdf:Bag>
>     <rdf:li><some:requirement/></rdf:li>
>     <rdf:li><and:someOthers/></rdf:li>
>   </rdf:Bag>
> </earl:passes>

> implies

> <earl:passes>
>   <new:requirement/>
> </earl:passes>

This is equivalent to the example that I gave yesterday with the
earl:derivedFrom property.

> cwm can do this with log:implies (I forget what the log namespace
> refers to though) - we just need to be able to express it with the
> right syntax. Is it possible to use RDF Schema -

Personally speaking, I'd steer well clear of any RDF solution which
required use of the log: namespace; it's non-standard and not
particularly clearly defined.

> <rdf:about>
>   <rdf:Bag>
>     <rdf:li><some:requirement/></rdf:li>
>     <rdf:li><and:someOthers/></rdf:li>
>   </rdf:Bag>
>   <rdfs:subClass new:requirement/>
> </rdf:about>

> or am I breaking something here? (And if it is possible does that
> introduce a requirement to understand RDF schema for EARL processing
> that wassn't already there?)

You're breaking several things there; I'm not entirely sure what
you're trying to do.

> We will also, I suspect, want to identify the things that were
> included to draw the conclusion. While this is not strictly
> necessary, being able to check them is helpful. It means that if one
> of those conditions changes we can retest the computed results
> without needing to retest all the things that led to the inference.

This was the purpose of the earl:derivedFrom property that I
introduced yesterday. A sketch of a scenario to illustrate this is
given below:

T1, T2 are tests
TG1 is the group of tests which contains T1 and T2

assertion-1 says that X passes test T1
assertion-2 says that X fails test T2

assertion-3 says that X fails TG1, and that this assertion is derived
from assertion-1 and assertion-2

[X is changed so that it passes T2]

assertion-4 says that X passes test T2

assertion-5 says that X passes TG1, and that this assertion is derived
from assertion-1 and assertion-4

> (my brain isn't sufficiently wired into RDF syntax today to write
> the examples - can anyone help?)

Similarly, I'll rework this sketch in RDF/XML on Monday if people
want.
-- 
Nick Gibbins                                            nmg@ecs.soton.ac.uk
IAM (Intelligence, Agents, Multimedia)             tel: +44 (0) 23 80592831
Electronics and Computer Science                   fax: +44 (0) 23 80592865
University of Southampton

Received on Friday, 27 September 2002 11:47:04 UTC