<jo> scribe: Jo
<scribe> scribe: Phil
https://www.w3.org/2020/08/19-md-odrl-profile-minutes.html
Ben: all actions done
RESOLUTION: Accept minutes of previous meeting
Jo: a number of new joiners, would anyone like to introduce themselves?
Ilya: creditor / debtor though restrictive by Michelle's colleagues
<mark_bird> https://github.com/w3c/market-data-odrl-profile/blob/2020-09-02-MB/discussions/2020-09-02/topics.md
Ben: wrote up some example on Github in sentences
<jo> https://github.com/w3c/market-data-odrl-profile/issues/17#issuecomment-682561225
Ben: used promisse and promisor
for example
... a couple restrictions on a solution
... the object of the duty is not the neccessarily the party
creating the duty
... and the option done to the object is not necessarily
beneficial to the party
... maybe actor and receiver best of the options?
Jo: options..
... actor /re
... subject /object
... promoissor /promisse
... obligator /obligatee
... so 4 options, but some concerns
Ilya: one concern is if this
meanings can float how do we know from a machine pov what
applies?
... might be fine for a lawyer, not a computer
... one sugestion is to make the term static for the duration
of the agreement
Ben: subject, predicate, object
e.g. x will pay Y, D will consent to E
... what should we call the subjects and objects
Ilya: the problem we have is that the identity changes by design so how does the computer decide
Ben: when a policy becomes an agreement, at that moment the agreement occurs all values are set
Ilya: so vocab is dependant on state of negotiation?
Ben: no, we offering a different policy, "offer" vs "agreement"
Ilya: if you have a human then they can apply the proper identity, but how do computers make a distinction what verb applied?
Ben: working assumption is if I
were a provider, my policies would be left open (no assignee
yet)
... assignee only populated in an "agreement" policy
... actor doing a payment for example is not specified until
the agreement
... we can give guidance in the standard
Ilya: i dont think that
helps
... humans in future rarely involved, if terms can change the
computer cant make the decision
Ben: in ODRL core model
action-related names are given
... put pattern is generic
... we can streamline
Ilya: we appreciate that , but still see a problem down the line
Ben: let's take it off line
Casper: in ODRL relation is
function, but we could have hierarchy
... we could allow sub-properties that inherit and have both
human and machine readable
... a kind of a half-way house
Jo: maybe an elaboration of this
is needed
... Laura's observation on switching round the role
Laura: the fact that the assignee is defined at time of agreement satisfies me but I see the overall concern
Jo: lets take Ben's suggestion to take this off-line to bring clarity to this
Mark: temporal object has a third
object that references the two
... now definitions can change over time, but have a single
point of reference
... is there any reason not to have temporal support?
Ben: feedback is that
implementors need stability and track of change
... it is a step away from ODRL
... Casper suggested offering temporal aspects to general
ODRL
... i believe ODRL group will receive the suggestion
generously
Ilya: ODRL may want to adopt themselves?
Ben: yes
Ilya: even in the media world there are right that change over time
Jo: Ben to take an action to go to ODRL community group
Ben: do we all want all ODRL
constructs temporal?
... we will have to make a decision from an implementation
point of view, what is temporal and what is not
Ilya: i think that we should make it a generic notion
Ben: if assigner or assignee
changes we would version the permission, not properties
... actions, duties, assets and permission definitely need
versioning
... e.g. if the assigner changes we version the permission
Ilya: if we have to change the report from licencee?
Ben: the change is then in the duty
Ilya: so we roll up temporal aspects to highest order object
Ben: important this is simple to implement, so roll up of temporal aspects helps. It is a balance.
<jo> ACTION: Ben to approach ODRL Community Group with proposal for a temporal profile and report back to this group with reaction and likely timescales if favourable
Jo: so again action is Ben to take to ODRL community group
<jo> PROPOSED RESOLUTION: This gorup favours the notion of temporal object
RESOLUTION: This group favours the notion of temporal objects
Jo:
Mark: Did we want to think about other properties?
Ben: now is the moment to raise that
Mark: topics page:
https://github.com/w3c/market-data-odrl-profile/blob/2020-09-02-MB/discussions/2020-09-02/topics.md
... reads through "Properties of Resources"
Ben: i want to free to update the
standard with all of these terms
... at any time they can be ammended
... if any are not clear or potentially unclear please could we
hear from all now
... i have started adding terms to the standard
<jo> https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html
Jo: do we need platform?
Ben: not a description of the
resource itself, so no
... we will come to those terms but they don't describe the
resource
... "location" is a hot topic, we will come to that too
... its on permission not resource
Ilya: we do have data sets that blur the lines
Ben: i think the permission
handles this
... it's not a description of the resource itself
Laura: is content type on the list?
Ben: content type is but is dependant on asset class
<jo> scribe: Jo
Phil: Content type is much over-used - Laura's point re text, pictures etc. may need to be captured
ben: some descriptions may help us route back if there is no descriptor
ilya: maybe asset class would be useful
ben: asset class is definitely
e.g. indices
... the content type is within that
<scribe> scribe: phil
Mark: possibly having a different term for this particular use may free us up later
Ben: its not a sub-type of asset
class
... we could use it in two contexts?
Olga: is it free form?
Ben: keen to use a controlled vocabulary
Mark: intraday?
Ben: intraday is a "lazy flag", we could drop it
Ilya: nettable resources, should
be add?
... we receice content from 3 different providers for same
user
... some contrcat allow netting of cost, ie count one
Ben: sounds like a permission element, not resource
<jo> ACTION: Ilya and Olga to provie illustration of what is meant by nettable
Jo: too short of time for next
topic
... is not necessary to vote yet on resource terms before
including them in the standard
Jo: hearing none
<jo> ACTION: Ben to convene further discussion as to the creditor/debtor discussion
<scribe> ACTION:
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/RESOLUTION: Accept minutes of last meeting// Succeeded: s/pary/party/ FAILED: s/ ACTION: Ben to further the Creditor and Debtor discussion// Succeeded: s|s/ ACTION: Ben to further the Creditor and Debtor discussion//|| FAILED: s/ACTION: Ben to further the Creditor and Debtor discussion// Succeeded: s|s/ACTION: Ben to further the Creditor and Debtor discussion//|| Succeeded: s/Ben to further the Creditor and Debtor discussion// Present: Phil Jo Ben Casper_M Fred_S Ilya_S Josh_C Laura Mark_B Mark_D Michelle_R Trisha_P Jeremy_B Adam_H Adam_D Regrets: renato Paul_K Chris_C David_S Tom_D Rachel_K Found Scribe: Jo Inferring ScribeNick: jo Found Scribe: Phil Inferring ScribeNick: Phil Found Scribe: Jo Inferring ScribeNick: jo Found Scribe: phil Inferring ScribeNick: Phil Scribes: Jo, Phil ScribeNicks: jo, Phil Agenda: https://w3c.github.io/market-data-odrl-profile/agendas/md-odrl-profile-agenda-2020-09-02.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: ben ilya olga WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]