Requirements

From Permissions and Obligations Expression Working Group
Jump to: navigation, search

Contents

POE Requirements

NOTES on creating the Requirements document

  • Each use case will be analysed and a final set of requirements developed (per UC) and then normalised
  • Each requirement will then be categorised into:
    • Requirements related to the Model
    • Requirements related to the Vocabulary
    • Requirements related to an Encoding
  • Within each of these categories, each requirement will be noted as:
    • An extension or addition
    • A change to the existing
    • A removal/deprecation
  • Criteria will then be applied to ranked/order each requirement, including:
    • Business support for this change
    • Commonality of the change (ie not specific to a domain/sector)
    • Impact on existing implementations

NOTES on the editing process

All UCs are split up into three groups, requirements retrieved and added to this page by the named editor:

Timeline/Milestones:

NOTES on discussing and approving requirements

All members of the POE WG are invited to comment on requirements. Any comment should include the name of the author of the comment and optionally a timestamp. (Please take care that 2 empty lines are between the last comment of a requirement and the heading of the next one.)

Each requirement has a status which indicated by one of the following:

  • Status: Proposed
  • Status: Under consideration
  • Status: Approved or Partially Approved (optional: <link to relevant resolution>)
  • Status: Rejected or Migrated (to another Requirement)

All members of the POE WG are invited to vote on all requirements to get them to the approved or rejected status.
For a vote please add your name or initials to the Vote item by using

  • +1 for approving it
  • -1 for rejecting it
  • 0 to indicate this requirements needs further clarification (you should add a comment too)

Below each requirement this list of items should be shown:

  • ReqType: ...
  • Source: ...
  • See also requirement ... (optional)
  • Status: ...
  • Vote:
  • Discussion (below)

Categorised Requirements

POE.R.DM Data Model

POE.R.DM.01 Define how constraints on a party can be expressed (Migrated)

Use Cases constraining a party of a permission/prohibition/duty can be covered by either defining a party instance which already includes this constraint (e.g. Party with the UID="...xyz" = all persons with an age above 18 years), or by applying a Constraint instance to the corresponding party with a specific role (as currently no constraints are defined for that purpose party-role-constraints need to be added). A single option for applying a constraint to a party (of a specific role) should be defined.
(Note: The current data model of a Constraint provides no explicit statement of the subject of the constraint, the default subject is this permission/prohibition/duty, an explicit subject may be added by the semantics of a constraint term from the constraints vocabulary.)

Renato Iannella There is still no descriptive Use Case for this? A Party has a a Scope attribute that could be used? And there is an existing Recipient Constraint?

The requirement refers to use case UC.01 R11 as source and this source says "Ability to express conditions based on the user nature (academic, commercial, etc.)". This raises the question: how to express such a nature? Currently a Party has only a function (assigner, attributedParty ...) and a scope (Individual, Group ...). In a conversation with the contributor of this use case this example was provided: "It should be possible to express 'this permission applies only to persons of academic nature'". From that the requirement was inferred to consider the nature of a person as constraint on a party of a policy. The current constraints includes only "recipient" as party-related term, a solution could be to have each term of the Role of a Party vocabulary also as term of the Constraints vocabulary - but this is already a currently not existing solution for the requirement. Michael Steidl 2016-06-09T06:45:00Z

--Víctor Rodríguez-Doncel 08:33, 9 June 2016 (UTC) I understand we are collecting requirements, no solutions. So for the moment, I would just add this requirement as it is.

Renato Iannella I am still trying to clarify the requirement. For the example given: 'this permission applies only to persons of academic nature' - is this a constraint on the Assignee, or a constraint on the use of the Asset?

I see it as a constraint applying to the Assignee Michael Steidl 2016-06-15T16:20:00Z

Michael Steidl 2016-06-20T14:00:00Z - requirement edited after POE teleconf of 2016-06-20

POE.R.DM.02 Define target of a constraint

By the current specification - http://w3c.github.io/poe/model/#constraint - a constraint applies to a Permission, Prohibition or Duty as a whole.
Uses cases show that it should be possible to define the target of a constraint inside a Permission, Prohibition or Duty: e.g. a constraint of human age applies to the Assignee, a constraint of play time applies to Assets (of type audio or video), etc.
To implement this requirement an optional property "target" is added to Constraint. The target property takes values from this enumeration: Asset, Party, Action. Further it provides uid and function as optional qualifiers of Asset and Party values. - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

POE.R.DM.03 Introduce policy template

The current data model assumes a policy instance includes all required data explicitly. This should be extended to policy instances which include explicit data and variables for values which are defined by parameters provided by an access to this template.
To implement this Requirement the Policy Types should be extended by Template. Property values using this syntax Template:Variable-name should be replaced by values provided at the time of accessing this template by parameters (parameters in the URL used for accessing the template or as http request body using JSON format). - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

Renato Iannella Clarification: A mechanism to say this Policy is a Template, and hence not all values will be expressed, and in some cases, values will be (string) variables defined externally?

Yes, what Renato writes meets what the requirements intends to express Michael Steidl 2016-06-09T06:45:00Z

The Requirement can perhaps be concisely stated as "Be able to qualify a policy as Template" --Víctor Rodríguez-Doncel (talk) 11:24, 25 August 2016 (UTC)

POE.R.DM.04 Support versioning policies

The Data Model should be extended to support the versioning of a policy. In addition to the existing identifiers of a policy means for expressing a version of this policy should specified.
To implement this Requirement an optional property "version" should be added to Policy. Rules for the value of version: must be a positive integer, a higher number than in an other version indicates a newer version. Default value of version is 1. - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

Renato Iannella Clarification: Is this simply a new version attribute on the Policy?

Michael Steidl 2016-06-23 15:52 CEST - a new version attribute of the Policy is an option.

POE.R.DM.05 Set a global price for all permissions of a policy

It should be possible to define the price for duty/duties of payment for all permissions of a policy in a global way - while currently the payment duty must be defined for each permission individually.
To implement this requirement the already existing "duty" is added to Policy as property and the semantics of Duty and duty need to be modified accordingly. - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

Renato Iannella The Model does support having a single Duty (eg payment) and then the individual Perms/Prohibs point to it. Is this requirement a short-cut to simply allow a Policy to have a direct Duty (that must be honoured before any Perms/Prohib is actioned)?

What Renato states as option of the Data Model is not implemented correspondingly into e.g. the XML Encoding: there it is not possible to define a duty as child of the policy root element. So maybe this is more an Encoding than a Data Model requirement. Michael Steidl 2016-06-09T06:45:00Z

--Víctor Rodríguez-Doncel 08:37, 9 June 2016 (UTC) It is very often the case of a policy/rule being repeated once and again with slight variations. I agree with the idea that mechanisms to avoid redundancies as much as possible are "encoding" issues.

Michael Steidl 2016-06-18T20:15:00Z requirement edited.

POE.R.DM.06 Support relative time constraints

Extend the temporal constraints by setting a time reference, any period in the rightOperand refers to this point in time.
To implement this Requirement "relativeTimePeriod" is added to Action for Constraints. Further an optional property relativeTimeReference is added to Constraint, this property takes a value from a vocabulary. This vocabulary provides concepts like at least "Start of event", "End of event", "Point in time of publishing the asset", and optionally more. In addition an optional property relativeTimeRelatedReference is added, this property holds the identifier for an entity scoped by the relativeTimeReference vocabulary term. (E.g. the event for "End of event".) - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach
For a relativeTimePeriod constraint the rightOperand has to provide a time period as value.

Renato Iannella I assume this is a new Vocab term. Perhaps TimeDelay (a period of time you need to wait before exercising the Perm). How will the reference time be specified?

Michael Steidl 2016-09-06 19:01: as advised at the POE call on 8 August the OWL Time Ontology - https://www.w3.org/TR/2016/WD-owl-time-20160712/ - was reviewed. As its item 5.2 outlines the ontology builds on a strict reference system. But that exactly should be overcome by this requirement.

POE.R.DM.07 Define a category property for class Party

A property of the class Party should define the category of the Party.

Renato Iannella What is the Use Case? We deliberately left out defining any characteristics of Parties (except for UID, role) and suggested using external Vocabs (eg vCard)

If the current text of UC.01 R17 is not sufficient to show the need for this requirement then the contributor should refine it, please Michael Steidl 2016-06-09T06:45:00Z

Víctor Rodríguez-Doncel 08:31, 9 June 2016 (UTC): While having a minimal vocabulary is a good design choice, some kinds of parties are mentioned very recurrently in actual licenses/policies. For example, "academic users" (users belonging to an entity of academic nature), "non-academic users" or having membership in a particular institution.

Renato Iannella is an example use case the ability to state that the Assignee of a policy is any party of category "academic user" ? Or is it that the use of the content is only allowed by parties of category "academic user"?

Víctor Rodríguez-Doncel (talk) 11:42, 25 August 2016 (UTC): Within the CLARIN licenses for language resources Clarin conditions, one of the requirements is AFFIL "The user needs to be affiliated with some community, e.g. a community of researchers through a university or research institution (x=EDU) or a community of language research and technology researchers more generally (x=META)". It should be expressable that the assignee of the policy is any party of category EDU.

Michael Steidl 2016-09-06 17:38: Victor, I think this need can be covered by a constraint which targets the Assignee party. See the Requirement above.

POE.R.DM.08 Add a category property to Asset

A new property of the class Asset should define the category of the Asset.

Renato Iannella ) What is the Use Case? We deliberately left out defining any characteristics of Assets (except for UID) and suggested using external Vocabs (eg Dublin Core type)

If the current text of UC.01 R17 is not sufficient to show the need for this requirement then the contributor should refine it, please Michael Steidl 2016-06-09T06:45:00Z

--Víctor Rodríguez-Doncel 08:40, 9 June 2016 (UTC) The current ODRL specification states that a "A Group specifies that the scope of the relationship is the defined group with multiple individual members" and it can only be applied to parties. This requirement states that it would be very useful having the ability to make Groups of assets and Groups of policies as well.

Renato Iannella Clarification: For "groups of assets" is the use case the ability to state that Asset with UID ABC123 is a "group" of assets, hence the perms (etc) applies to each individually. (We assume this in the current ODRL, the resolution of the UID into multiple individual assets is system-specific). Does the Use case also include the ability to use relational operators? That is, thin Perm is applied to Asset Group ABC123 and can only be used on one of the individual assets?

Renato Iannella Can you explain more about what it means that a Policy is defined as a Group?

Víctor Rodríguez-Doncel (talk) 11:50, 25 August 2016 (UTC): Groups of policies can be syntactic sugar for handling multiple policies (e.g. deprecating, referencing, etc.) or multiple assets. Section 3.11 of the 2.1 model is confusing with its use of x:collection. But if defining characteristics for Assets is made through external vocabularies, the same idea can be used for Policies. The anomaly would be then having "Groups" of parties; but this can be left for historical reasons.

POE.R.DM.09 Complex Constraints

Express complex constraints such as 'No use in UK after 7 days'.

Renato Iannella ODRL can currently express that constraint.

Michael Steidl 2016-06-23 15:54 CEST I share Renato's view, see http://dev.iptc.org/RightsML-Combined-Example-geographic-and-time-period

POE.R.DM.10 Extended Relations

Being able to tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship.

Michael Steidl 2016-09-06 18:29: is it ok to enhance the experimental Extended Relations - http://w3c.github.io/poe/model/#extended-relations - to a production level?

POE.R.DM.11 Remedies

Being able to define remedies for violated prohibitions or duties (cf. ODRL Remedies)
To implement this Requirement the class Remedies should be specified, parent class Rule, with the definition: "Remedies is a rule which indicated a requirement that must be fulfilled in the case of violating any Permission, Prohibition, Duty or the Policy as a whole." A corresponding property remedies should be added to Permission, Prohibition, Duty and Policy. - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

POE.R.DM.12 Grouping party entities

Being able to assign multiple individuals of type Party to a Group for which permissions/prohibitions/duties can be specified.

Michael Steidl 2016-09-06 18:47: as long as the members of a Party Scope representing a group or collection of persons (Group, All, AllConnections, All2ndConnections, AllGroups) stay anonymous these scopes can be used. If identified persons should be defined as group members/connections the question is: is doing that a job for ODRL - let's assume a group has 1 billion members (Facebook)? Or is it required to have a license-processor-external system for testing if the id of a person is registered with a group/as a connection which is a party in an policy?

POE.R.V Vocabulary

POE.R.V.01 Add rights holder terms to Roles of a Party Vocabulary

Add roles for "distibution rightsholder" and "IPR holder" to the Roles of a Party vocabulary.

Renato Iannella Would just a "rightsholderParty" work?

Michael Steidl 12:48, 17 June 2016 (UTC) Contributor (Victor) should clarify

Víctor Rodríguez-Doncel (talk) 11:56, 25 August 2016 (UTC): The Use Case describes the need for specifying who is the original IPR rightsholder and who is the current rightsholder of the rights that have been transferred. For example, I may be the author of a journal paper (originally owning the exploitation rights over the work) but after a few days I may have transferred the distribution rights to Springer. Both Springer and I should be representable. This is what the UC expresses. However, introducing terms related to rights may be dangerous and conflictive. I would leave this aside, at most being part of a profile.

POE.R.V.02 Add term for redepositing to Duty Vocabulary

Add a term for the duty to deposit assets derived from this asset back to the source of this asset to the Duty Vocabulary.

Renato Iannella Clarification: by "redeposit" you mean that the newly derived asset must be submitted back to the same repository?

Michael Steidl 12:55, 17 June 2016 (UTC) requirement edited

POE.R.V.03 Add concept of 'unit-of-count' to Duty Constraint Vocabulary

Being able to define a 'unit-of-count' for duty actions, e.g., define what should be reported via odrl:inform (for each userAccount).

POE.R.V.04 - POE.R.V.07

  • Status: WITHDRAWN by contributor

POE.R.V.08 Add terms to the Action Vocabulary

Add the action contract, acknowledge copyright and acknowledge to the Action Vocabulary

Renato Iannella Could "reviewPolicy" work? otherwise this list of artefacts will be long.

Michael Steidl 13:00, 17 June 2016 (UTC) "reviewPolicy" was made to request a human (= non-machine) to review the policy, maybe because of free-text right operands. But e.g. "acknowledge" requires an interaction of the Assignee back the Assigner, goes therefore beyond reviewPolicy.

POE.R.V.09 Add Linked Data related actions to Action Vocabulary

Add actions which are relevant to Linked Data scenarios (e.g., querying data, aggregating data, reading data, etc.) to the Action Vocabulary

Michael Steidl 2016-09-06 19:32: we need more precise terms - with definition.

POE.R.V.10 Add terms to the Roles of a Party Vocabulary

Add the role compensatingParty to the Party Role Vocabulary

Renato Iannella Clarification: what are the "and more" party roles?

Michael Steidl 13:00, 17 June 2016 (UTC) Does the contributor (Ben) want to provide more terms, else the requirement will be limited to "compensatingParty"

Michael Steidl 2016-09-07 09:38: "more terms" has been removed.

POE.R.V.11 New Party Category Vocabulary

Create a new vocabulary with a basic set of terms for the requested new category property of the Party class.

Michael Steidl 2016-09-06 19:34: we need also terms for a vocabulary requirement.

POE.R.V.12 New Asset Category Vocabulary

Create a new vocabulary with a basic set of terms for the requested new category property of the Asset class.

Michael Steidl 2016-09-07 08:06: we need also terms for a vocabulary requirement.

POE.R.V.13 - POE.R.V.14

  • Status: Migrated/merged

POE.R.V.15 Reference to Source License

Ability to link from a Policy or a Permission to the original (text-based) license.
To implement this Requirement "policyTextSource" is added to Asset Relations with a definition "The property specifies the natural language text Asset being the source for this policy. This source may cover more than expressed by this policy." The related asset identifies this text document. - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

Renato Iannella For a Permission/Prohibition, we could add a new Relation type ("source') but this would not work for a Policy (as it does not link to Asset via Relation) - so this could also be a Model change

Michael Steidl 2016-09-07 08:45: added suggestion of a Requirement implementation.

POE.R.V.16 Assertion Policy Type

It should be possible to define policies of type Assertion. An Assertion policy does not grant any permissions/prohibitions, but reflects policy terms that a party believes to have. For example, either an assignee can assert what terms they have over an Asset and/or an assigner can assert what terms they have over an asset.

POE.R.E Encoding

POE.R.E.01 Referring to external resources for defining payment fees

Define how to specify a fee by referring to an resource outside a policy document

Renato Iannella use case required

Michael Steidl 13:15, 17 June 2016 (UTC) Requirement changed.

Michael Steidl 2016-09-07 08:46: This use case is highly linked to the policy template case as in fact "this" policy provides no value for a property but indicates "the value can be found in that resource". This is slightly different from "the value is provided by a parameter when accessing the resource" but only slightly ...

POE.R.E.02

  • Status: WITHDRAWN by contributor

POE.R.R Processing Rules

POE.R.R.01 Define rules for matching permissions/prohibitions against specific use cases

The requested ability to check the compliance of a certain process and the tasks composing it with respect to the regulations requires to define rules for matching permissions/prohibitions against specific use cases.

Michael Steidl 2016-09-07 08:55: this is an extremly complex use case: it mixes the use of existing policies with a snapshot of a context and from that a new policy should be generated. This goes beyond the data model and processing model of the current ODRL design, creating a requirement requires a deep discussion.

POE.R.R.02 Define a language for controlling processing policies

A language should define processing rules for combining the results of matching multiple permissions/prohibitions against specific use cases to create an overall permission/prohibition status.

Michael Steidl 2016-09-07 09:01: See "Define rules for matching permissions/prohibitions against specific use cases"

POE.R.R.03 Define processing rules for versioned policies

Rules defining how different versions of a policy with the same identifier should be processed should be specified. To implement this Requirement these rules should be defined: i/ newer version always takes precedence, ii/ if the reference of the policy includes its version then this version takes precedence. The rule is held by a new versionConflic property of Policy. - Simon Steyskal (talk) 06:39, 21 October 2016 (UTC) requirement != solution approach

POE.R.R.04 Support to auto-generate a policy from a template plus provided parameter values

It should be defined how a policy template can be combined with a set of parameters (provided by a URL or other means of a http request) to generate a complete final policy (= variable values have been set by the parameters).

Michael Steidl 2016-09-07 09:08: see "Introduce policy template".

POE.R.R.05 Guidance on Rights Assignments through Aggregation and Derivation

Provide guidance and examples of managing rights assignments through aggregations. Perhaps we want to make sense of the concept of the 'minimally encumbered interpretation'.

Michael Steidl 2016-09-07 09:09: See "Define rules for matching permissions/prohibitions against specific use cases"

POE.R.R.06 Guidance on Specifying Subsets of Assets

Provide guidance and examples of specifying subsets of data as the object of the odrl:target predicate. Can subsets be defined dynamically (i.e by a query: rule-based and instantiated at runtime; or reference to a collection that can change over time)?

Michael Steidl 2016-09-07 09:14: See my comment on "Grouping party entities" - is the management of the relationships inside a collections of things (parties, assets) in the scope of ODRL?

POE.R.R.07 Guidance on Conflicting Permissions

Provide guidance and examples of managing conflicting permissions. (Does a conflict even make sense when we're talking of rights assignments?)

  • ReqType: Guidance
  • Source: ?
  • Status: Rejected
  • Vote:
  • Discussion (below)

POE.R.R.08 Guidance on the Provenance of Policies

Provide guidance and examples of expressing the provenance of the interpretation of the original document, recognising that the original source remains normative.

POE.R.R.09 Make policies accessible by URL

Encourage POE implementers to make policies accessible as a web resource by a URL and http content negotiation should be supported to deliver a specific request format.

  • ReqType: addition
  • Source: POE.UC.01 R18
  • Status: Approved
  • Vote:
  • Discussion (below)
    • "Encourage" in terms of optional?

Requirements-related notes on UCs

(These notes relate to the exclusion of requirements which are already covered by ODRL 2.1. They should clarify why requirements listed in a UC have not been included into this collection of requirements. These note should not be included into the UCR page on Github.)

  • UC.01 R4: this ability is covered by ODRL 2.1
  • UC.01 R6: this ability is covered by ODRL 2.1
  • UC.01 R8: this ability is covered by ODRL 2.1 (assignee party with a scope of Group)
  • UC.01 R10: this ability is covered by ODRL 2.1 (duty to attribute with a link to the attribution information)
  • UC.01 R11: this requirement was transformed into the requirement for constraints applying to a party and a corresponding vocabulary.
  • UC.01 R13: the POE for creating derived material is covered by the ODRL 2.1 Action Vocab term "derive", to defined POE for the derived asset can be expressed by a "next policy" = this R13 does not require new features
  • UC.01 R15: this ability is covered by ODRL 2.1 (interpret "condition" as constraint)
  • UC.04 R1: these documents needs a list of examples, see requirement "Prove that a list of existing licenses can be expressed/encoded" above as example

Removed Requirements

Withdrawn Requirements

POE.R.V.04 Add "action context" to Constraint Vocabulary

Add a term "action context" to the Constrants vocabulary to express in which context an action may be executed.

Renato Iannella This requirement seriously needs a use case! Context can mean anything.

Michael Steidl 12:55, 17 June 2016 (UTC) - Merriam Webster defines context as "the interrelated conditions in which something exists or occurs", by that I would define the context of an action as "The interrelated conditions in which an action on as asset is executed". And the right operand of that constraint should defined what conditions have to be met - and they need to be very clearly defined.

Michael Steidl 2016-09-06 19:16: as of today the UC.01 in Use_Cases has no R9 or similar requirement anymore.

POE.R.V.05 New Action Context Vocabulary

Create a new vocabulary for the context of an action and include at least terms for academic, noncommercial, evaluation use. The identifiers of these terms can be used as rightOperand values of a constraint.

  • ReqType: addition
  • Source: POE.UC.01 R9
  • See also requirement: "Add 'action context' to Constraints"
  • Status: WITHDRAWN by contributor
  • Vote:
  • Discussion (below)

Renato Iannella We have the "purpose" constraint..that seems to cover some aspects of "context". Again, a use case helps.

Michael Steidl 2016-09-06 19:16: as of today the UC.01 in Use_Cases has no R9 or similar requirement anymore.

POE.R.V.06 Add "party" to Constraints Vocabulary

Add a term "party" to the Constraints vocabulary to express that this constraint applies to a party of the policy.

  • ReqType: addition
  • Source: POE.UC.01 R11
  • See also requirement "Define how constrains on a party can be expressed"
  • Status: WITHDRAWN by contributor
  • Vote:
  • Discussion (below)

Renato Iannella This requirement needs a detailed use case

Michael Steidl 2016-09-06 19:21: as of today the UC.01 of Use_Cases has not R11 or similar requirement anymore.

POE.R.V.07 Add "meansOfDelivery" to Constraints Vocabulary

Add a term meansOfDelivery to the Constraints vocabulary to express ways/means for delivering the asset.

  • ReqType: addition
  • Source: POE.UC.01 R12
  • Status: WITHDRAWN by contributor
  • Vote:
  • Discussion (below)

Renato Iannella ODRL currently has "deliveryChannel" as a constraint

Michael Steidl 13:00, 17 June 2016 (UTC) "deliveryChannel" might need a clarification if also the technical basics of delivery are covered by it.

Víctor Rodríguez-Doncel (talk) 12:06, 25 August 2016 (UTC): I fully believe deliveryChannel suffices to match the definition of Metashare: "the medium (channel) used for delivery or providing access to the resource".

POE.R.E.02 Prove that a list of existing licenses can be expressed/encoded

In the linguistic domain many common licenses exist expressed by natural language. It should be shown that the licenses listed below can be expressed by a POE policy.

  • META-SHARE_Commercial_NoRedistribution
  • META-SHARE_Commercial_NoRedistribution_For-a-Fee
  • META-SHARE Commercial NoRedistribution NoDerivatives_For-a-fee
  • META-SHARE Commercial NoRedistribution NoDerivatives
  • META-SHARE NonCommercial NoRedistribution NoDerivatives_For-a-fee
  • META-SHARE NonCommercial NoRedistribution NoDerivatives
  • META-SHARE NonCommercial NoRedistribution_For-a-Fee
  • META-SHARE NonCommercial NoRedistribution

All of the above available at: http://www.meta-net.eu/meta-share/licenses

  • CLARIN RES+BY+NORED
  • CLARIN RES+BY+NC+NORED
  • CLARIN RES+FF+BY+LRT+NORED
  • CLARIN ACA+BY+NORED
  • CLARIN ACA+BY+NC+NORED

https://www.clarin.eu/content/license-categories

  • ReqType: prove of usability
  • Source: POE.UC.01 R5, POE.UC.02-S3
  • Status: WITHDRAWN by contributor
  • Vote:
  • Discussion (below)

Renato Iannella This is NOT a requirement. Someone has to do this work as an analysis activity, then propose requirements from that. Víctor Rodríguez-Doncel (talk) 12:08, 25 August 2016 (UTC): Please remove this section.

Migrated Requirements

POE.R.V.13 Temporal Constraint

Set a temporal constraint (ex. after some date) for the exercise of the object of the odrl:action predicate.

  • ReqType: Clarification
  • Source: POE.UC.03
  • Status: Migrated/merged
  • Vote:
  • Discussion (below)

Renato Iannella Clarification, if this is a fixed dateTime, then ODRL supports this.

Michael Steidl In the news business this use case is known: images of a sports game (think of the current football Euro 2016) may be published only 15 minutes after the game has ended. This needs a facts based time trigger.

Michael Steidl 2016-09-07 08:13: this requirement is covered by the "relative time constraint" requirement.

POE.R.V.14 Using time spans in Temporal Constraints

Being able to specify an access period/interval as rightOperand of a constraint.

  • ReqType: addition
  • Source: POE.UC.16
  • Status: Migrated/Merged
  • Vote:
  • Discussion (below)

Michael Steidl 2016-09-07 08:23: this requirement is covered by the "relative time constraint" requirement.