Re: ODRL Profile for Linked Data

Well,

at least this is the feedback I was expecting, I dont have any other 
issue to ask for the moment. And you?
I will follow Sabrina's suggestions...

Víctor

El 04/06/2015 12:13, Sabrina Kirrane escribió:
> 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 <mailto: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.
>
>


-- 
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
Facultad de Informática
Universidad Politécnica de Madrid

Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 91336 3672
Skype: vroddon3