Re: ODRL Profile for Linked Data

Hi Guys,

I'm available for the call today, however if you prefer to postpone that's  
OK too.

@Victor

I see that you only added four update opertations (INSERT, DELETE, LOAD  
and CLEAR). SPARQL 1.1 update caters for five update operations (INSERT  
DATA, DELETE DATA, DELETE/
INSERT, LOAD and CLEAR) and five graph management operations (CREATE,  
DROP, COPY, MOVE and ADD). Any reason not to include all of them?

Other questions/comments

General structure:
a)Propose new Section - Namespaces before Actions

b)At the moment actions and assets are defined at the top of the document  
and new concepts after each user story.
Does it make sense to include all of the new concepts at the top and then  
simply refer to them in the scenarios? That all the new vocabulary is in  
one place.

Assets)
Could we also have graph patterns and SPARQL Views?

S1)
Does it make sense to include a type (Explicit/Implicit) which can be used  
in the case of a conflict to differentiate between explicit and inferred  
policies (e.g. explicit overrides implicit)

S6)
a) It looks like defaults for conflict resolution defaults are declared  
for both PolicySet and the Policy level.

Could we use constraints for dynamic conflict resolution e.g. I might want  
to say that PolicySets override Policies whereas someone else my see it  
the other way around. (You already have something in S13 - however it is  
specific to the policy whereas I was thinking of something more general)

b) odrl-ld:involvedPolicy seems strange what about componentPolicy or  
containedPolicy?

S7) In the example remedies are associated with duties and prohibitions.  
These are defined at different levels of granularity. Should these be  
different concepts?

S_X) Can we add some scenarios around negotiation, consistency and safety?

Regards,
Sabrina

On Thu, Jun 4, 2015 at 10:56 AM, Simon Steyskal <simon.steyskal@wu.ac..at>  
wrote:
>> I wonder how can we specify this beyond an English sentence.
>
> haha yes, we may have to hack some fancy semantics together for that ;)
>
>> But... which should be the reference software to validate the  
>> expressions?
>
> unfortunately there doesn't exist any (official) validator for SHACL  
> yet, but most of the constraints are expressible in SPARQL anyway.  
> Holger >Knublauch gave it a first shot in [1], but he is currently  
> focussing on implementing a SHACL API for TopQuadrant's TopBraidComposer.
>
> cheers, simon
>
>
> [1] https://github.com/HolgerKnublauch/shacl-lite
>
>
> ---
> DDipl.-Ing. Simon Steyskal
> Institute for Information Business, WU Vienna
>
> www: http://www.steyskal.info/  twitter: @simonsteys
>
> Am 2015-06-04 11:45, schrieb Víctor Rodríguez Doncel:
>> Yes, hence my concern about "having conflicts for the conflict  
>> resolution"
>> odrl:conflict may declare prohibitions take precedence in general, but
>> one specific permission may gain precedence if so declared with the
>> odrl-ld:precedenceOver.
>> I wonder how can we specify this beyond an English sentence.
>>
>> Also, I think the RDF Shapes spec is truly clear. But... which should
>> be the reference software to validate the expressions?
>> I have peeked here http://www.w3.org/2001/sw/wiki/ShEx, but I am
>> unsure about it...
>> Where should I look at?
>>
>> Víctor
>>
>>
>> El 04/06/2015 11:28, Simon Steyskal escribió:
>>> 4) Well to some extend.. While odrl:conflict only allows to state that  
>>> in case of conflicting rules either the permission or prohibition  
>>> takes >>>precedence, odrl-ld:precedenceOver would allow to specify  
>>> that specific rules (if they are applicable too) can take precedence  
>>> over others >>>regardless their respective type.