Permissions and Obligations Expression Working Group Teleconference

24 Oct 2016

See also: IRC log


renato, scribe, ivan, Serena, Brian_Ulicny, phila, Simon
Stuart, Michael, Ben, Caroline, Victor


<scribe> scribe: simonstey


renato: approval of last week's minutes


<Brian_Ulicny> +1

<Serena> +1

scribe: no objections; minutes accepted

UC from BSIG

<renato> https://docs.google.com/document/d/15nbqGY20IIGbTQOzKxzw59TLzwfPpRZu-1KKA97phKg/edit

renato: we got some UC from the book industry study group

<phila> Happy, sure

renato: we'll now go through them one by one

<Serena> sure

POE.UC.28: Enhance discovery of library collection materials

UNKNOWN_SPEAKER: some req. read more like principles rather than actual requirements
... not sure what library-to-library licensing actually entails


<phila> simonstey: Second what Phil said, this library to library case isn't special from our POV. You can define an agreement, one library is the assignee, one is the assigner etc.

phila: one response is "this is already covered" and I think so too

22.1 -> already covered


<Brian_Ulicny> +q

<phila> simonstey: This could be a super valuable asset that you physically display but only for the case of someone to look at t, not to lend it out etc.

Brian_Ulicny: not sure what "display for discovery" actually means

renato: maybe we should ask them for some clarification

22.2 -> ask BISG for clarification

<phila> simonstey: This is related too the grouping of assets?

<phila> ... The chapters, graphs etc.

renato: later on we have req. referring to breaking down the asset into individual parts

22.3 -> already satisfied (i.e. defning perm/.. for individual subcomponents and group them together in a policy)

22.4 -> already satisfied


phila: that's potentially a bigger problem than just applying perm/prohibitions
... this I believe is a hot topic in digital publishing
... if you have an ID for your document, how are you identifying individual parts?

ivan: I don't think this WG should try to invent something
... we should take whatever's already out there
... I think the issue here is whether this can be used for ODRL
... the gettyimage is a difficult example in that context
... if I have a resource, can I assign perm/proh to that resource
... and subsequently to parts of that resource too?

renato: well.. partially
... we want to have something that allows us to define "parts" of an asset

ivan: I have URI1 describing certain rights, URI2 describing some other rights
... can I say -> for everything that's not covered by URI1, look for it at URI2

renato: no, I don't think so

phila: it is not easy to define such "default behavior/set of metadata", we did that in POWDER
... I think we are getting well beyond what this WG should do
... I'm not proposing POWDER as a solution, just wanted to mention it

<Brian_Ulicny> +q


ivan: from an ODRL point of view, structure isn't that important

Brian_Ulicny: I think there are 2 issues here
... 1) whether rights of parts are communicated back to the whole

<phila> simonstey: Regarding this issue of parts of a whole, applying things to the whole or parts... this is put here in the domain of libraries, but we also have it coming from TR. They boil down to this use case.

ivan: I want to be a bit cautious about saying "just put a URI on it"
... I would not dismiss the fact that someones uses a blank node for describing a resource

<phila> POWDER eg

phila: I keep talking about powder
... it's an example of a policy
... line 7 -> beginning of an audit list (dr = description resource)
... 1) IRI set 2) set of descriptors

[phila explains example POWDER policy]

<ivan> http://w3c.github.io/web-annotation/selector-note/index-respec.html

ivan: that's the document I was referring to
... section 3 the selectors

<ivan> http://w3c.github.io/web-annotation/selector-note/index-respec.html#TextQuoteSelector_def

ivan: an example expressed in JSON defining sections of a document
... this (or a combination for that matter) is able to define specific parts of a document
... what the rec. behind that doesn't have is URIs for it

<ivan> http://w3c.github.io/web-annotation/selector-note/index-respec.html#json-examples-converted-to-fragment-identifiers

ivan: here you do get URIs (ugly ones though)
... I don't know whether it's possible for ODRL to define perms/prohi. for something that's defined like that

renato: you are talking about example 6 of the first link you've posted?
... I recall that we've a req. that requires to be able to define constraints on assets too

<ivan> http://w3c.github.io/web-annotation/selector-note/index-respec.html#SelectorRefinement_def

ivan: yes, it could be seen as constraint on a URI

[renato & ivan talking about possible realization in ODRL]

renato: we'll ask them to give us some clarification

23.6/7 -> implementation specific

23.1-5 -> ask BISG for clarification


ivan: 24.3 refers to the fact that certain publishers may provide free "samples" of their books
... but this would then actually result in two different assets


<phila> simonstey: I don't think we can enumerate all the possible purposes

renato: long long time ago we had something like "subscription"

<Serena> I agree with Simon

<phila> simonstey: I think the fact that we can add time to permissions etc. means ODRL covers these use cases


25.1 -> supported using grantUse/nextPolicy

24.1-24.5 -> covered, need some investigation though

change of meeting time

<phila> phila: Will circulate new time of 12:30 UTC which, in UTC terms, is half an hour later than the current meeting time, but will be half an hour earlier on northern hemisphere calendars after DST ends

Summary of Action Items

Summary of Resolutions

[End of minutes]