Call for requirements towards an ODRL Linked Data profile
Purpose of the ODRL Linked Data profile
The ODRL Linked Data profile must provide the vocabulary enabling:
- The description of data licenses that may be applied to Linked Data resources (RDF documents, RDF statements, OWL ontologies, etc.)
- The description of access policies governing conditionally the access to Linked Data
General profile requirements
Regarding general access control requirements for Linked Data, Sabrina has listed a pretty impressive amount of those in Chapter 3.4 of her PhD Thesis clustered into:
- Specification
- Granularity: Existing access control strategies for RDF, resources are specified at several different levels of granularity. Namely, triples, named graphs, views, triple patterns, graph patterns with filters and graph patterns without filters, ontology concepts, ontology individuals, and graph nodes and edges.
- Underlying Formalism: Access control languages should be based on formal semantics, as it decouples the meaning of the policies from the actual implementation.
- Reasoning: It should be possible to propagate policies based on the semantic relations between authorisation subjects, objects and access rights.
- Condition Expressiveness: When it comes to access control, it should be feasible to specify conditions under which a request will be permitted or prohibited.
- Attributes, Context & Evidences: As the requester many be unknown to the system prior to submitting a request, access should be based on properties pertaining to the requester, commonly know as attributes, instead of traditional identities. It should also be feasible to dynamically activate policies based on context.
- Heterogeneity & Interoperability: Access control for open distributed environments, such as the web, needs to be able to support a wide variety of disparate policies, resources and users. One of the primary goals of standardisation is to maximize interoperability.
- Enforcement
- Negotation: In order to protect user privacy, it should be possible for both the service provider and the requester to define polices and exchange credentials until and agreement has been reached. The process is commonly known as negotiation.
- Explanations: Rather than simply granting or denying access, the policy should also provide details of how the decision was reached. Such explanations would be of benefit to both the requester and the policy owner, making it easier for the requester to understand what is required of them and for the policy owner to troubleshoot potential problems.
- Conflict Resolution: Conflicts between both explicit and implicit policies should be resolved automatically.
- Administration
- Delegation: It should be feasible to temporarily transfer access rights to other users.
- Consistency & Safety: In order to ensure the access control system is complete and accurate, insertion and deletion of policies should be controlled. It should not be possible to elevate your own privileges or to assign permissions that would make data inaccessible to everyone.
- Usability: The specification and the maintenance of access control policies should be as simple as possible.
- Understandability: It should be easy to understand the interplay between policies.
- Implementation
- Effectiveness: In order to work in practice, access control enforcement and administration needs to be efficient.
- Distributed: In order to ensure scalability, it should be possible to cater for the distributed specification and enforcement of access control policies.
- Flexibility & Extensibility: The system should be capable of handling frequent changes to policies, user, access rights and resources. In addition, in order to provide support for different scenarios and future enhancements, the enforcement frameworks should be flexible and extensible.
Some of them target systems or actual implementations rather than the vocabulary itself, though.
(She will visit us at WU during the first week of May, so maybe we want to ask her to join us?)
Specific vocabulary requirements
These requirements describe the concepts and relations that should be present in the ODRL Linked Data profile
User Stories
S1: Monetary Benefit
As owner of a dataset, I want to be able to charge consumers for using my data. This fee should depend on the nature of use as well as data they actually want to consume.
S2: Granularity
As owner of a dataset, I want to be able to define policies for different levels of granularity of data. It should be possible to operate on triple level, subgraph level, as well as on the entire RDF graph representing the data itself.
S3: Licensing
As owner of a dataset, I want to be able to define licensing conditions for that dataset. Those conditions must be as expressive as common license vocabularies (cf. Creative Commons, etc.), i.e. pre-defined data licenses like PDDL, CC-Family, ODC, etc. must be representable.
S4: Actions relevant to Linked Data
As owner of a dataset, I want to be able to use/restrict actions which are relevant to Linked Data scenarios. Such actions include (but are not limited to): querying data, aggregating data, reading data, etc..
S5: Defining Preconditions for Policies
As owner of a dataset, I want to be able to define preconditions for my policies. It should be possible to state, that certain policies only apply within certain scenarios (i.e. when their precondition(s) hold). Those policies can include both permissions as well as prohibitions.
S6: Clustering Policies in Sets of Policies
As owner of a dataset, I want to be able to cluster a policies into sets of policies. Those policy sets may adhere to different conflict resolution strategies than their containing policies.
S7: Defining Remedies
As owner of a dataset, I want to be able to define remedies for violated prohibitions or duties (cf. ODRL Remedies)
S8: Extended Relations
As owner of a dataset, I want to be able to define more complex policies by combining permissions, prohibitions, constraints and duties using extended relations (cf. ODRL Extended Relations)
S9: Temporal Constraints
As owner of a dataset, I want to be able to define fine-grained temporal constraints for my policies. It should be possible to define absolute as well as relative timeframes in terms of days, minutes, dates, etc. and to define that certain policies are only valid within those timeframes.
S10: Specifying Default Behavior for missing Information
As owner of a dataset, I want to be able to define not only conflict resolution strategies for my policies and policy sets, but also default behavior in terms of missing information. E.g., I want to be able to state that, if the execution a certain action is not explicitely prohibited, it is permitted.
S11: Specifying Default Behavior for Parties
As owner of a dataset, I want to be able to state whether policies defined for a group of assignees affect shall affect policies defined for single assignees. E.g., If everyone is prohibited to use my dataset but Alice is allowed to use it, does the more general policy "overrule" the more specific one?
S12: Implicitely affected Actions
As owner of a dataset, I want to know which actions are implicitely affected by permissions/prohibitions of others. I'm not only interested in the subsumption hierarchy of actions (e.g. use is more general than read) but also in part-of relationships of actions (e.g. to share something involves distributing it). To satisfy my needs, the ODRL core model should be extended by appropriate relationships between actions.
S13: Precedence Relationship
As owner of a dataset, I want to be able to define precedences among permissions, prohibitions and duties. This would allow to easily map policies into defeasible logic (cf. A Modelling and Reasoning Framework for Social Networks Policies (Section 9.1))
S14: Responsibility
The consumer of a dataset is entirely responsible, to the exclusion of the dataset author and any other persons, for compliance of the use and reuse of the data with the regulations set by the dataset owners, and with the local regulations regarding use, including those regarding import, export, and use of encryption software.
Scenarios of application
Scenario #A: Conditional Linked Data Server
Much as illustrated by the demo portal, http://conditional.linkeddata.es, it is possible to:
- a) assign a ODRL policy a RDF named graph.
- b) conditionally serve RDF triples according to the ODRL policy.
prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
prefix dct: http://purl.org/dc/terms/ .
prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# .
prefix gr: http://purl.org/goodrelations/ .
prefix odrl: http://www.w3.org/ns/odrl/2/ .
http://conditional.linkeddata.es/ldr/policy/ee32f675-ccae-4ca9-a544-3c07abf0b16e
a odrl:Offer ;
rdfs:comment "Individual triples are available upon payment of 1 euro cent" ;
rdfs:label "License1Cent" ;
odrl:permission [
odrl:action odrl:reproduce ;
odrl:duty [
rdfs:label "Pay" ;
gr:UnitOfMeasurement rdf:Statement ;
gr:amountOfThisGood "1" ;
odrl:action odrl:pay ;
odrl:target "0.01 EUR"
]
] .
(note: the above example still uses the old model for payments. The angle and 'at' symbols have been removed.)
Derived from this scenario the following requirements appear:
- RA1: The CRUD operations should be inequivocally described (i.e., only one term to declare "Read" access, and not the many that now could be interpreted). Maybe also in tighter relationship with the Linked Data Platform vocabulary.
- RA2: Richer manners of expressing payments and prices are required. In the ConditionalLinkedData example, an externa schema (GoodRelations) was taken.
- RA3: The range of syntactically valid expressions is too large to grant that any valid expression will be parsed. This is promising too much. A more constrainted syntax is needed (avoiding recursions, a limit in the nested elements, etc.)
- RA4: A default policies for actions must be implicitly declared (if nothing said about 'delete', then allow 'delete', etc.).
Scenario #B: Licensed Linked Data for Language Resources
Language resources are highly valuable resources now being massively translated to Linked Data. See the diagram here: Linguistic Linked Data Cloud Different Language Resource Catalogs exist, like the one of CLARIN, or the one of META-SHARE, LRMAP, Linghub, etc. These resources need to be browswed and queried, and the license information must be in a machine-readable form. This is essentially the big requirement from this use case: represent the most typical clauses found in the licenses of the Language Resources as Linked Data.
A number of more precise [Requirements https://www.w3.org/community/ld4lt/wiki/Metashare_vocabulary_for_licenses] can be found in the work within the Linked Data For Language Technologies (LD4LT) W3C Community Group. In particular, up to 18 requirements were found.
- RB1 Distribution Rightsholder vs. IPR holder
- RB2 Temporal constraints
- RB3 Common licenses in the linguistic domain
- RB4 To neatly represent conditions of use
- RB5 Represent the obligation to inform the licensor
- RB6 Represent the obligation to redeposit
- RB7 Only MetaShare members
- RB8 Academic / noncommercial / evaluation use
- RB9 Attribution condition
- RB10 Conditions on the user nature
- RB11 Specification of features on the distribution
- RB12 Specification of the condition to distribute derived material and the condition to create derived material
- RB13 Specification of the fee, within and outside the license
- RB14 Specify the next policy
- RB15 Use license templates
- RB16 Define license categories
- RB17 Referencing standard licenses
- RB18 Mapping the XML MetaShare licensing terms to RDF
Misc
Maybe we want to take LDP Access Control and their (outdated?) Wiki into account too (e.g. using LD profile of ODRL as access control vocabulary for LDP 2.0 etc.)