ODRL Validator

[vroddon]

I have published the following at http://odrlapi.appspot.com/ :

• An ODRL Validator for RDF.
• A collection of 43 test cases for the validator

The system is based in the corresponding API, propertly documented and published and open (github, Apache License).
You can also test the API within the documentation (Swagger).

To the best of my knowledge, all the validations have been implemented excepting the inheritance preprocessing mechanism and one validation in the complex constraints. I think they will be ready by today.

For the rest, I will be very happy if you report any error or improvement that you see.
For each of the 43 samples I attach the expected result and a tiny summary. Please note that in several cases the spec has been unclear to me and I was unsure about the expected validation result.

Also, please note that I have introduced an additional level of validation:

• valid - compliant with the spec
• valid with warning - compliant with the spec but ill formed in my opinion
• not valid - not compliant with the spec

I have used some of the Simon's SHACL Shapes (duly updated, as the model has changed much since May), some new SHACL Shapes, and some algorithmically verified constraints; Michael's Excel has proved also very useful. I lean on TopQuadrant SHACL implementation, whose legal status I ignore. I have not tested the system's ability to deal with concurrency.

http://odrlapi.appspot.com/

[vroddon]

For validation purposes, the following example is a diffcult one:

@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix p1: <http://odrlapi.appspot.com/profile> .

#valid. With logical constraint defined in an a profile

<http://odrlapi.appspot.com/samples/sample053>
    a odrl:Set ;
    dct:source "victor";
    odrl:profile <http://odrlapi.appspot.com/profile> ;
    odrl:permission [
        odrl:target <http://example.com/book/1999> ;
        odrl:assigner <http://example.com/org/paisley-park> ;
        odrl:action odrl:play ;
        odrl:constraint [
            p1:unknown <http://example.com/p:88/C1> ;
        ]    
   ] .

<http://example.com/p:88/C1> 
    a odrl:Constraint ;
    odrl:leftOperand "media" ;
    odrl:operator odrl:eq ;
    odrl:rightOperand odrl:online .

How to determine that the anonymous constraint (under the rule) is an odrl:Constraint or an odrl:LogicalConstraint? There is no obvious procedure to determine if this is an ill-formed "Constraint" or a well formed "LogicalConstraint" with a profile-defined operator. My proposal (only for implementors):
(1)- if it has no properties, the policy is invalid
(2)- if it has any property different from leftOperand/operator/rightOperand, it is a LogicalConstraint
(3)- if it hasn't, it is a Constraint

I am not totally sure, though.

[vroddon]

Update on the validator (http://odrlapi.appspot.com/):

• Validation of logical constraints has been added.
• Processing of inheritance mechanisms has been implemented. With cycle verification and topological sorting of policies.
• Verifications on undefined terms in absence of profiles
• OWL validation has been disabled (takes too long)
• 65 test cases have been proposed

Update on the API:

• A new method to canonicalize has been added. Pending to be documented.

Pending tasks:

• Documentation as indicated by Ben, including an enumeration of all the validations done.

[riannella]

@vroddon an odrl:Constraint must have the 3 properties (leftOperand, operator, rightOperand).
Is that sufficient to determine if it is a Constraint or LogicalConstraint?

if not, we can mandate that a Logical Constraint use a @type
(like we do for Asset/Party Collection)

[vroddon]

I am neutral about how to determine if it is a Constraint or a LogicalConstraint. In practice, implementations will not suffer much, I think. (And for the evaluator I implemented the logic above but I can change it easily).

Is it mandated that AssetCollection/PartyCollections have their type explicitly declared? I had not read it in the list of requirements for the validator. Also, I realize that having one and only one source should be verified for AssetCollection/PartyCollections. I will add a couple of test cases more for the validator.

[riannella]

Yes, we don't mandate it as such, we say, for example:

An AssetCollection may have none, one, or many refinement property values of type Constraint

So you should assert that the thing is an AssetCollection, but you may not

[vroddon]

Ok! Great. In such a case, everything is correct.
What we do check is that if the AssetCollection has a refinement, then it must have a odrl:source (see sample055, sample065, sample066 and sample067).

[vroddon]

Up to my knowledge:

• The implemented normalizations match those in the spec (can be tried from the API docs)
• The implemented validations match the spec

I am not aware of any feature from the spec not being validated. Next task: write the list of normalizations and the list of verifications done.

We have now 72 test cases.

[vroddon]

A further validation has been implemented at http://odrlapi.appspot.com/ ("A remedy must not refer to a Duty that includes a consequence Duty.") and added two new test cases (we have now up to 74 sample policies).

[vroddon]

@riannella @benedictws @simonstey @nitmws @iherman

I have just published 5 normalization steps and 25 validation rules in the following wiki. https://www.w3.org/2016/poe/wiki/Validation

I have tried to collect any validation check derived from the IM that has been proposed so far (Michael, Simon, etc.). Is there anybody aware of any other validation not listed there?

They are all implemented at http://odrlapi.appspot.com/

[vroddon]

@simonstey, I understood you are publishing tomorrow also some SHACL shapes.
Wouldn't it be great linking them to the validation rules https://www.w3.org/2016/poe/wiki/Validation?
Namely, "Shape X validates rules Y,Z" etc.

I wrote some at https://github.com/oeg-upm/licensius, but they are still not clean nor commented. Where do you have yours? I dont find them here https://github.com/simonstey/ODRL-SHACL-Shapes, but I would be happy to work jointly!

[riannella]

Great work @vroddon

What about this in Policy Metadata:

If a Policy has the dc:isReplacedBy property, then a processor must consider the first Policy void and must retrieve and process the identified Policy.

[riannella]

@vroddon @benedictws @simonstey @nitmws @iherman

We need to bring all the testing stuff together into a package for developers.

@benedictws Will oversee this.

The two documents needed are:
https://github.com/w3c/poe/blob/gh-pages/test/test-regime.md
https://github.com/w3c/poe/blob/gh-pages/test/test-suite.md

And the results (from implementors) goes here:
https://w3c.github.io/poe/test/implementors

We should also reference the CR Exit Criteria in:
https://github.com/w3c/poe/blob/gh-pages/test/test-regime.md

[vroddon]

If a Policy has the dc:isReplacedBy property, then a processor must consider the first Policy void and must retrieve and process the identified Policy.

I am terribly afraid this would be matter for the Evaluator, rather than the Validator (I don't see the transformation either, except from self-destruction of the policy). And now... ...a new word has slipped into the discussion: "void" ;-)

[riannella]

"void" introduced here: #237

[iherman]

It is important to have at least a skeleton, or a set of links, into the two new pages ASAP. We cannot call for a CR with empty pages...