Re: Test suite skeleton

This raises a question: should we include SHACL files for each of the 
examples?

For:

- it seems a helpful thing to do;
- pointing to the SHACL playground gives ODRL implementers a way to test 
their data without us having to do it.

Against:

- it creates a dependency on another WG's progress (but they're already 
at CR and the implementation report seems they're *just* over the line).

- It might be seen, erroneously, as a suggestion that SHACL is the only 
way to validate ODRL data.

None of this will obviate the need to cite multiple implementations of 
an ODRL processor in the implementation report.

Phil

On 09/05/2017 08:05, Simon Steyskal wrote:
>> A smart WG will create a validator (somehow). Something for the
>> SPECIAL project?
>
> fwiw, following SHACL shapes check for those conditions:
>
> odrl:PolicyShape
>     a sh:NodeShape ;
>     sh:targetClass odrl:Policy ;
>     sh:nodeKind sh:IRI ;
>     sh:property [
>         sh:path [
>             sh:alternativePath ( odrl:permission odrl:prohibition )
>         ] ;
>         sh:minCount 1 ;
>     ] .
>
> odrl:PolicyTypeShape
>     a sh:NodeShape ;
>     sh:targetSubjectsOf odrl:permission ;
>     sh:class odrl:Policy .
>
> odrl:PolicyTypeShape2
>     a sh:NodeShape ;
>     sh:targetSubjectsOf odrl:prohibition ;
>     sh:class odrl:Policy .
>
>
> you can test them here http://shacl.org/playground/ using following data
> graph:
>
> @prefix odrl: <http://example.org/ns#> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix schema: <http://schema.org/> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
> odrl:Set rdfs:subClassOf odrl:Policy .
>
>
> [] a odrl:Set;
>     odrl:permission [
>         a odrl:Permission ;
>         odrl:target <http://example.com/asset:9898> ;
>         odrl:action odrl:reproduce
>     ] ;
>     odrl:prohibition [
>         a odrl:Prohibition ;
>         odrl:target <http://example.com/asset:9898> ;
>         odrl:action odrl:modify
>     ] .
>
> <http://example.com/policy:0099>
>     odrl:permission [
>         a odrl:Permission ;
>         odrl:target <http://example.com/asset:9898> ;
>         odrl:action odrl:reproduce
>     ] ;
>     odrl:prohibition [
>         a odrl:Prohibition ;
>         odrl:target <http://example.com/asset:9898> ;
>         odrl:action odrl:modify
>     ] .
>
> <http://example.com/policy:00992>
>     a odrl:Set .
>
> <http://example.com/policy:valid>
>     a odrl:Set;
>     odrl:permission [
>         a odrl:Permission ;
>         odrl:target <http://example.com/asset:9898> ;
>         odrl:action odrl:reproduce
>     ] ;
>     odrl:prohibition [
>         a odrl:Prohibition ;
>         odrl:target <http://example.com/asset:9898> ;
>         odrl:action odrl:modify
>     ] .
>
> br simon
>
> ---
> DDipl.-Ing. Simon Steyskal
> Institute for Information Business, WU Vienna
>
> www: http://www.steyskal.info/  twitter: @simonsteys
>
> Am 2017-05-08 16:35, schrieb Phil Archer:
>> Dear all,
>>
>> I just failed to have this ready for today's call but it exists now
>> and I'll extend it before next week's F2F.
>>
>> As we have discussed several times, I believe we need a test suite.
>> Next week's first agenda item will be to discuss the concept of an
>> ODRL Process - what does it mean etc. These are all tied together of
>> course.
>>
>> All I've done so far is to take the first normative statement from the
>> model doc and created a mini test suite for it, which in fact is
>> copied from the old example 1. The current text in the model says:
>>
>> A Policy MUST have the following properties:
>>
>> The uid identification of the Policy.
>> The type indicating the specific type of Policy.
>> A permission and/or prohibition Rule.
>>
>> So I copied example 1 as a valid example and then deliberately 'broke
>> it' to create three invalid instances.
>>
>> The idea is that you build an ODRL Processor (whatever we decide that
>> means) and you can test that it accepts the first example and raises
>> an error with the other 3. For valid examples, I'm suggesting that we
>> include an 'interpretation' line, i.e. this is what this policy means.
>>
>> Some points:
>> - this is just an example;
>> - it will need to change if we formally resolve that odrl:Set is the
>> default;
>> - the external files will need to be created and served via conneg.
>>
>> This is what I meant on today's call about the complexity of the test
>> suite etc. increasing with every rule we introduce.
>>
>> A smart WG will create a validator (somehow). Something for the
>> SPECIAL project?
>>
>> Phil

-- 


Phil Archer
Data Strategist, W3C
http://www.w3.org/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Tuesday, 9 May 2017 07:55:57 UTC