Re: ODRL Profile for Linked Data

Hi!

> 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)

Do you mean as a general property for policies? Or as an additional 
conflict resolution strategy in addition to permit,prohibit, and 
invalid? I would prefer the latter.

> 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?

a) ah, I guess you mean that e.g. Alice would use her .shacl constraints 
which give policy sets precedence over policies together with the 
knowledge base, whereas Bob could use his constraints to define it the 
other way round?

b) you are right, my fault ;) I'm fine with both options!

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

Hm? Duties and prohibitions are different concepts, yes ;)

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

The more the better! Regarding negotiation, we might want to leverage 
from SHACL's NotConstraints [1].

[1] http://w3c.github.io/data-shapes/shacl/#not

cheers,
simon

---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-06-04 12:13, schrieb Sabrina Kirrane:
> 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 [1]
>> 
>> ---
>> DDipl.-Ing. Simon Steyskal
>> Institute for Information Business, WU Vienna
>> 
>> www: http://www.steyskal.info/ [2] 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 [3], 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.
> 
> 
> 
> Links:
> ------
> [1] https://github.com/HolgerKnublauch/shacl-lite
> [2] http://www.steyskal.info/
> [3] http://www.w3.org/2001/sw/wiki/ShEx

Received on Friday, 5 June 2015 08:38:55 UTC