owl:oneOf (was Re: Issue #8: Extensibility of outcome values)

Hi,

As a side note, I think so far we had a wrong understanding of OWL. For 
example, lets say a tool outputs the following:

  <earl:outcome rdf:resource="http://example.org/#myValue"/>

The parser will not automatically output an error that ex:myValue is a 
"wrong value", but it will assume that ex:myValue is one of the listed 
outcome values. So if we want to say that earl:outcome can not be 
ex:myValue then we will have to do it in a different way, and a higher 
level logic (like rules) will have to initiate the "wrong value" error 
in an EARL reader application.

We need to rethink the owl:oneOf constructs that we have. In some cases 
(like the outcome value) they *may* be replaceable by RDF lists.

Regards,
   Shadi


Carlos Iglesias wrote:
> 
> Hi group,
> 
> After our initial discussion about EARL's issue #8 [1] at the last teleconference I'm going to try to summarize my point of view about current constraints applied to outcomes to facilitate further discussion.
> 
> Even when the general "spirit" of RDF is to be as open as possible, IMO there will be always certain constraints that are necessary when modelling, especially when you're dealing with well defined scenarios as the world of software testing or QA in general are.
> 
> The current model is apparently robust enough to cover every use case we have found until now. Apparently, there is no request at the moment we could not cover using one of the current classes, or creating subclasses of them if further shades of meaning are necessary. Additionally outcomes has been one of the more stable and interoperable parts historically in EARL, which could be seen as a proof of its completeness.
> 
> With respect to the new potential use case mentioned (performance testing), I still think that if you want to record "validity" results (you may define a minimum performance to pass or fail) one of the current values could be used also without any problem, but I also think that this new use case could show us that we may need a new TestResult property (or properties) to help us record this kind of measures.
> 
> E.g. we could use a readability test that outputs a readability value in a scale from 0 to 100, and we have defined a test case where we need a 70 value to pass the test. If we run the test case and get a score of 60, we should record a fail as a result but we may obviously also want to record the specific value of the measure (60) for the record.
> 
> Finally, if we choose to provide a completely open model for the outcome values, we should be aware of the fact that interoperability could be seriously reduced once people decide to create new outcome values for those that should be just variants of the current ones. Additionally we will leave the door open to potentially "bad practices" as the use of new "warning" outcome values could be.
> 
> 
> [1] - [http://www.w3.org/WAI/ER/EARL10/issues#outcomes]
> 
> Regards,
>  CI.
> 
> --------------------------------------
> 
> Carlos Iglesias
> 
> CTIC Foundation
> Science and Technology Park of Gijón
> 33203 - Gijón, Asturias, Spain 
> 
> phone: +34 984291212
> fax: +34 984390612
> email: carlos.iglesias@fundacionctic.org
> URL: http://www.fundacionctic.org 
> 
> 

-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff Contact for the Evaluation and Repair Tools WG |
World Wide Web Consortium (W3C)           http://www.w3.org/ |
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Tuesday, 5 June 2007 09:22:05 UTC