Re: [SKOS] test cases

On 25 Jun 2007, at 16:08, Antoine Isaac wrote:

> Hi Sean,
>>
>> [I sent this to Diego on Friday and failed to cc the list :-(]
>>
>> I've started a wiki draft document:
>>
>> http://www.w3.org/2006/07/SWD/wiki/SKOS/TestCases
>>
>> Without a clear idea of what a test case is, and what we need to  
>> be testing, it's difficult to define a template! However, it will  
>> be useful to at least begin to gather information about the kinds  
>> of test cases that we need and particular ideas relating to test  
>> cases for issues, so a rather sparse initial attempt is here:
>>
>> http://www.w3.org/2006/07/SWD/wiki/SkosTestTemplate
> [just want to say that I find it a great beginning ;-)]
>>
>> Two questions that I think we need to consider w.r.t testing are:
>>
>> o What /is/ a SKOS implementation?
>> o What kinds of things are considered "in scope" for tests. e.g.  
>> is hierarchical display something that we can provide tests for?
> Personally my first choice would refer to a SKOS 'implementation'  
> for an instantiation of the SKOS model (e.g. RDF/XML file) defining  
> concepts and concept schemes. For these, perhaps  we would be  
> interested in consistency and entailment (following the OWL type of  
> tests [1])

Consistency/inconsistency and entailment tests were the ones that I  
could definitely think of :-)

> But of course in some contexts a SKOS implementation could denote  
> tools making use of SKOS (e.g. browser). Perhaps we should use  
> 'SKOS tools' to refer to the latter category.

Pinning down vocabulary is an excellent idea. I like the use of  
"tools" for browsers and the like. I'm not sure that I'd use the word  
"implementation" for an instantiation of the SKOS model though --  
implementation to me has different connotations.

> And of course I think we cannot provide formal tests for this  
> category. As you hint at, I guess we cannot certify that a  
> hierarchical display correspond to what was expected in the test.  
> Shall we have kind of 'normative tool implementation guideline'  
> test category, if we want to have such tests in our test set?

I think we do want these somewhere though -- this is clearly an  
important aspect and guidelines or suggestions for tool behaviour  
would be a good resource for tool builders. I propose we use the  
draft document as somewhere to collate such "tests" in the first  
place, and then refine later.

	Sean

--
Sean Bechhofer
School of Computer Science
University of Manchester
sean.bechhofer@manchester.ac.uk
http://www.cs.manchester.ac.uk/people/bechhofer

Received on Tuesday, 26 June 2007 07:50:00 UTC