See also: IRC log
<renato> Any volunteers to scribe: https://www.w3.org/2016/poe/wiki/Scribes
<scribe> scribe: michaelS
<scribe> scribeNick: michaelS
<victor> (if nobody else does, i can scribe, although i shall be speaking much i think)
<renato> https://www.w3.org/2016/08/22-poe-minutes
renato: any change requests?
RESOLUTION: last weeks minutes are approved
<victor> Sure. You may want to see the UCs https://www.w3.org/2016/poe/wiki/Use_Cases
<renato> UC.01 https://www.w3.org/TR/poe-ucr/#langResources
<renato> See wiki: https://www.w3.org/2016/poe/wiki/Use_Cases#POE.UC.01_Permissions_and_obligations_for_language_resources
victor: worked on the language of
this UC and removed any features already implemented
... highlights 5 points
... 1. Policy template - and he added examples
<victor> https://www.w3.org/TR/dwbp-ucr/#requirements-for-data-on-the-web-best-practices
victor: when a template is defined also variables in this template should be defined
<simonstey> ..:license [ a odrl:License; odrl:price .. ] wouldn't that be more elegant?
simonstey: should these variables be defined individually or by a single statement?
victor: there could be a mix: two
variable are the same across many template-base policies
... and only one variable is changes for individual
policies
simonstey: is concerned that this may go beyond agreed ODRL features - would make license expresses much more complex
victor: saw simonstey's point
renato: would a full now policy be created from a template?
<victor> http://company.com/odrlpolicytemplate1?price=1000¤cy=EUR
victor: thinks about having a
link to a template plus parameters defining the varibales
... and shared an example link
<victor> (I believe this should not be part of ODRL, but illustrates a possible implementation)
simonstey: would prefer a variant with templates holding default values
<renato> michael: versionsing of the template?
<renato> ...how to refer to real policy wand with an identifier?
renato: shared the concern that such dynamic creation of policies is too complex - as e.g. also an API for creating an instance would be required
<victor> <a_resource> dct:license <https://example.com/uri.of.an.odrl.expression/> .
victor: shared a triple which should be used to set a license for a resource
<simonstey> +q
renato: this means: that's a
policy having all but the asset defined
... the user has to take care that the related policy does not
change over time
simonstey: a policy type set can exist without an asset
<victor> Odrl 2.1 ontology https://www.w3.org/ns/odrl/2/ODRL21
simonstey: suggested to create a policy type "license" for this use case
<victor> (second excerpt of code in that document)
<simonstey> +1 to that ;)
michaelS: in the news business linked policies without an included asset are quite common
renato: we may need to make the definitions of the policy types clearer
victor: about issue 2. Ability to group parties, assets and policies
<simonstey> +1 to be able to group assets & policies
<simonstey> +q
simonstey: supports this
requirement
... is there a way to assing a party to a group?
<victor> I copy here verbatim the 2.1 model spec: "group: indicates that the Party entity represents a group. The group consisting of many individual members. The linked Permission, Duty or Prohibition is applicable for each member of that group. For example, a (constrained) Permission to play a movie 5 times is valid for each Party member or the Duty to pay 3 EUR has to be fulfilled by each Party member."
renato: no, the current ODRL does not support expressing which entities are member of a group
simonstey: thinks about creating a group asset and then it should be possible to add links to the related individual assets
renato: what should be done with a group of policies?
simonstey: currently a single
license should include all permissions and prohibiltions - but
it would be convenient in some cases to split this up into
multiple policies
... issue: how to deal with conflicts among policies - should
it be possible to indicate rules different from conflict
checking inside a policy
victor: about issue 3. Information on the rightsholder
<simonstey> only point to the last previous rights holder?
victor: creator will never change - and the current rights holder should be included
renato: could be added as a term to the vocabulary
victor: about 4. Inform and
Redeposit
... feels that this is not included in the current vocab
renato: the acceptTracking may cover that
<renato> https://www.w3.org/TR/vocab-odrl/#term-inform
<renato> https://www.w3.org/TR/vocab-odrl/#term-informedParty
michaelS: isn't victor's case going in the other direction: the assignee has to send the (modified) asset back to the assigner
victor: for the redeposit we need a new term
ren
renato: yes
<victor> https://www.w3.org/TR/dwbp/#licenses
<renato> uc.02 https://www.w3.org/TR/poe-ucr/#conditionalAccess
victor: this links shows a similar need by that W3C group
renato: had a long list of comments on this example 5 earlier this year
victor: thinks the text of
example 5 is valid
... many requirements are pending, primarily
vocabulary-related
renato: we have to consider if
the requested terms are sufficient generic - too specif terms
should not go into an ODRL vocab
... We could add links to specifications in another
vocabulary
<simonstey> +q
victor: not sure if all details of UC.02 should be kept in the ODRL scenario - as it goes a bit beyond it
simonstey: this type of use could be covered by an ODRL Profile - giving clear guidelines how this UC should be managed
victor: this is ok with him
simonstey: but then we need a spec for this profile!
<simonstey> +1 to that
<Serena> +1
renato: ODRL could share a note about this profile together with any of its own recommendations.
<renato> https://www.w3.org/TR/poe-ucr/#extDecPaymentAmount
victor: this UC is highly related to the template issue - see above
<renato> UC.21 https://www.w3.org/TR/poe-ucr/#constraintScope
victor: pointed at the example
renato: the current constraints
apply primarily to the actions - we have to consider opening
this up
... opening up a constraint to any property of a policy would
make the use more flexible
... thanked victor for going over all these UC in detail
renato: no changes since the last
call
... asked Serena to take action
renato: will add a note about the
ODRL profile discussed today
... thanked all, was a productive call
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: michaelS Inferring ScribeNick: michaelS Found ScribeNick: michaelS Present: renato michaelS victor Serena Ivan WARNING: Replacing previous Regrets list. (Old list: Phil, Victor) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ ben, philA Regrets: ben philA Sabrina Agenda: https://www.w3.org/2016/poe/wiki/Meetings:Telecon20160829 Found Date: 29 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/29-poe-minutes.html People with action items:[End of scribe.perl diagnostic output]