-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ODRL Validator #242
Comments
For validation purposes, the following example is a diffcult one:
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): I am not totally sure, though. |
Update on the validator (http://odrlapi.appspot.com/):
Update on the API:
Pending tasks:
|
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. |
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 |
Ok! Great. In such a case, everything is correct. |
Up to my knowledge:
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. |
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). |
@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/ |
@simonstey, I understood you are publishing tomorrow also some SHACL shapes. 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! |
Great work @vroddon What about this in Policy Metadata:
|
@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: And the results (from implementors) goes here: We should also reference the CR Exit Criteria in: |
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" ;-) |
"void" introduced here: #237 |
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... |
I have published the following at http://odrlapi.appspot.com/ :
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:
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/
The text was updated successfully, but these errors were encountered: