This document discusses the importance of providing a formal semantics for ODRL.

Introduction

The Open Digital Rights Language (ODRL) is a policy expression language that can be used to represent permitted and prohibited actions over a certain asset, as well as obligated actions.
The ODRL Information Model formally defines the core abstract concepts (classes) of the model and their properties by means of an OWL 2 Ontology (which is available in various format at https://www.w3.org/ns/odrl/2/).
The ODRL ontology can be used to write machine-readable policies (sample policies are available here https://w3c.github.io/odrl/bp/) and associate them to digital assets. The advantage of representing policies with a machine-readable language is that you can provide certain useful services on policies, e.g. you can search for policies that meet certain criteria, you can easily retrieve all the permissions a user has on a given picture or all the prohibitions associated to a movie.
There are other types of services that would be useful to provide on a set of ODRL policies. They are described below in the Scenarios section. In order to automatically provide those services on a set of policies we need to be able to formally specify their meaning, i.e.: we need to be able to automatically compute if: The meaning of having an ORDL permission, prohibition or duty is specified as follows:
  1. Prohibition: A Prohibition disallows an action, with all refinements satisfied, to be exercised on an Asset if all constraints are satisfied.
  2. Duty: A Duty is the obligation to exercise an action, with all refinements satisfied. A Duty is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised.
  3. Permission: A Permission allows an action, with all refinements satisfied, to be exercised on an Asset if all constraints are satisfied and if all duties are fulfilled.

Scenarios

Policy Monitoring

Various autonomous agents interact in an open interaction system and perform various types of actions. These actions, with their type (e.g. a payment), various parameters (who paid, how much they paid, etc.) and the time instant at which they are done, are digitally represented in a 'world state' or 'system state'.
(What model of data (ontology) is used for representing the state of the world?)

A set of ODRL policies (P) regulate the behaviour of those agents, every policy contains some rules (R) that are prohibitions, duties, or permissions.

Policy monitoring (or compliance checking) is a continuous process that consists of computing at every instant of time:

Monitoring or compliance checking are useful, for example, for being able to:

Simulation may be used by consumers for a what-if analysis and evaluate if the performance of an action on a digital asset will I violate one of its policies.
In this scenario, it is assumed that agents are free to perform all actions, even prohibited ones. A permission is interesting when it is an exception to a prohibition.

Access Control

Goal: Match access requests with ODRL policies determining access control to stored digital resources

Access control policies can be used to determine access by users or software agents to digital resources.

This is particularly important in decentralised systems where the users are the entities responsible to grant or deny access to the data and are responsible to define or adhere to a set of policies that satisfy their preferences.

By using these policies in an algorithm to match incoming access requests for data, a system can provide a fine-grained access control mechanism to its users.

In this scenario, if an agent does not have permission to access certain data, it will not access the data, the prohibition is regimented and cannot be violated.

Typically in this scenario, the entities responsible to grant or deny access to the data would write odrl:Offer policies (or new types of policies can be created, e.g., preference, requirement). The agent trying to access the data would write odrl:Request policies and the final agreement between the parties can be stored as an odrl:Agreement (associated with the odrl:Offer and odrl:Request policies).

License composition

Two resources differently licensed ("policed") need to be integrated in a new work. Which range of policies will be compatible with these two previous policies? Are these two policies compatible at all? The works of Governatori, Villata et al., DALICC and many others addressed this problem, but their results and ideas were never incorporated into ODRL.

Validation

ODRL is being used in a Language Resource Data Portal. Anybody can freely upload a resource, and anybody can post ODRL policies associated to them. The ids of the content resources and the assigners are verified, but the rest is left to the users. However, if they upload broken or malicious policies, they could break the system (e.g. a policy with 1 million rules). How to validate the ODRL policies so that they are conformant with a limited subset of them? ODRL Validator and Evaluator Sandbox

Planning

I want to do an action, I don't have permission to do it, what do I have to do to get permission to do it? Which is the sequence of messages to be exchanged within a protocol?

Semantics of Permission, Prohibition, and Obligation

Constraint, Refinement, Duty

In order to clarify the semantics of ODRL it is important to clarify the different semantics of the: Although the range of the constraint and refinement properties is the same class (i.e. the Constraint class) their meaning is different:

Sematics of Permission

Goal: determine if a Permission is valid and if the performance of a certain action generates a violation. The process for computing the satisfaction of constraints, the satisfaction of refinements, the fulfillment of duties is left to individual implementations. But given these values, all ODRL Evaluators should agree on the state of Permissions and on the violations generated.
In ODRL 2.2., a Rule that belongs to the Permission class is valid (the action is permitted) if all constraints of the Rule are satisfied AND all duties are fulfilled. Those two conditions together represent a validity condition. If one of those two conditions is not met, the Permission is invalid or not valid.
Therefore in order to evaluate if one permission is valid, it is necessary to perform the following steps:
  1. Evaluate the satisfaction of the constraints on the state of the world, output: satisfied, not satisfied;
  2. Evaluate the duties on the state of the world, output: fulfilled, not fulfilled (see below)
  3. If the constraints are satisfied AND the duties are fullilled then the permission is valid otherwise is invalid.
In a system it is crucial to detect the violations. If the default setting for the policy evaluator is: "everything is prohibited unless explicitly permitted", whenever an action is performed (or in access control there is a request to perform an action) it is required to check if the action was (is) permitted or not. This can be done by performing the following steps:
  1. When an action is performed (or planned or requested);
  2. For every valid permission (computed as above), evaluate if the action performed satisfies its refinements (output: satisfied, not satisfied). This means to check the value of the action, target, and assigner properties.
  3. If all the refinements are satisfied the permission is used (this may be important for those permissions that can only be used a limited number of times)(it is also possible that the action is prohibited by another Rule, we dicuss the semantics of Prohibitions below);
  4. If one of the refinements is not satisfied the action is not permitted by the permission under examination;
  5. If the action is not permitted by at least one of the permissions then there is a violation;

Sematics of Duty used as a validity condition of Permission

Goal: determine if a Duty is fulfilled. In ODRL 2.2., a Rule that belongs to the Duty class is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been performed.
The initial state of a duty is not fulfilled. In order to evaluate if a duty is fulfilled, it is necessary to perform the following steps:
  1. Evaluate the satisfaction of the constraints (output: satisfied, not satisfied) on the state of the world;
  2. Evaluate if the action of the duty, with all refinements satisfied, has been performed (output: satisfied, not satisfied) on the state of the world.
  3. If the constraints are satisfied AND the action has been performed the duty is fulfilled otherwise remains not fulfilled.
  4. Once a duty has been fulfilled, it cannot become not fullilled.
Problem: using the "compatible" ontologies for representing the knowledge regarding the state of the world and for expressing ODRL policies.

Example 22 from ODRL Information Model 2.2. The Party http://example.com/assigner:sony makes an Offer to play the target asset http://example.com/music/1999.mp3. The permission includes a duty for the compensate action that has a refinement of payAmount of $EU5.00. The semantics of Permission requires that the action of payment must be performed before to get a valid permission.
ID Duty Refinement (pay 5 euro) Duty status Permission status Permission Action+Refinement (play file) Violation
E22-1 not satisfied not fulfilled not valid performed possible violation depends on other permissions and default setting
E22-2 satisfied fulfilled valid performed permission is used

Sematics of Prohibition

work in progress.... (an active Prohibition is infringed by the regulated action (with all refinements satisfied) being exercised)

Sematics of Obligation

(In ODRL 2.2 there is not a class Obligation, there is a property obligation that connects a policy to an instance of the class Duty).

In ODRL 2.2., an Obligation

  1. is active (it starts to oblige someone to do something) if all the constraints of the Rule are satisfied (the constraints of the Rule represent an activation condition see below);
  2. an active Obligation becomes fulfilled when the regulated action (with all refinements satisfied) being exercised; Given that there is not a deadline the active obligation cannot become violated;
  3. an obligation may have one or many consequence property values of type Duty (is it a Duty or an obligation?)
Open problems:
  1. It is impossible to reason about deadline.
The notion of activation condition of a policy/norm is an important component in many policy models in the literature.
  1. An activation condition is a condition that when is satisfied results in a change in the state (deontic state) of the policy/norm.
  2. The satisfaction of the activation condition of a policy has to be evaluated on the state of the world (or state of the environment) where the interactions among agents are represented using a suitable notation.
  3. The satisfaction of the activation condition of a policy must be evaluated independently from the action regulated by the policy and it is the first component of a policy that must be evaluated.
  4. In some policy/norms models the satisfaction of the activation condition of a policy bounds some variables contained in the activation condition to the values that caused the activation condition to be satisfied. These bounded values are used also in other components of the active policy/norm.
Open problems:
  1. Meaning of the constraint of a rule: a constraint of a Rule is expressed as 'leftOperand operator rightOperand' (for example: spatial eq Germany) where the leftOperand is a property, what is the domain of the property? For example is spatial a property having as domain the class Agent?
  2. How is it possible to verify that the constraints of a Rule can be evaluated independently of the action regulated by the Rule?

Previous efforts

Section authored by Víctor. This section does not pretend to be part of a spec, but may serve as reference

Documents on "formal semantics" in W3C specifications

The W3C has produced several "Semantics" documents each of them with a different objective.

The RDF1.1. Semantics defines a model-theoretic semantics to determine the validity of RDF inference processes. A similar approach is followed by the OWL Semantics, a recommendation providing the direct model-theoretic semantics for OWL 2 and definingthe most common inference problems.

XPath (XML Path Language) is a language that can be used to navigate through elements and attributes in an XML document, and it also has formal semantics. XQuery (XML Query) is a query and functional programming language to query XML data. The "XQuery and XPath Formal Semantics" intends to complement the specification by defining the meaning of XQuery/XPath expressions with mathematical rigor; thus clarifying the intended meaning of the English specification, and ensuring that no corner cases are left out. For that regard grammar productions are given.

The POWDER specification provides a mechanism to describe and discover Web resources, and it also includes a Formal Semantics document. POWDER documents are XML documents which can be automatically converted, through a GRDDL transform, into a semantically rich version in RDF (POWDER-S). The "semantics" document describes how to make such transformation.

The PROV Ontology Working Group has produced 12 specifications to facilitate the interchange of provenance information in the Web (where provenance is …information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness"). Besides having published a PROVO Ontology to facilitate the expression of provenance as RDF, the family of documents also define an EBNF notation "which allows serializations of PROV instances to be created in a compact manner", a set of constraints to "ensure that a PROV instance represents a consistent history of objects and their interactions that is safe to use for the purpose of logical reasoning" and statements in the PROV Data Model are seen "as atomic formulas in the sense of first-order logic […and…] the constraints and inferences specified in PROV-CONSTRAINTS as a first-order theory".

ODRL Formalization

ODRL was created in in the early 2000's as an XML dialect to represent rights expressions to be used in the framework of Digital Rights Management systems; and its version 1.1 gained much spread [ODRL02]. Different ODRL profiles extended the vocabulary to satisfy the needs in different sectors. In 2011, an ODRL W3C Community Group was established, publishing soon after a new version 2.1 with major changes which included a new information model [Ianella15], a vocabulary [Ianella15b] and an Ontology [McRoberts15]. ODRL 2.1 became then a policy language.Other specifications in XML and similar to ODRL were MPEG-21 Rights Expression Language [Wang94], XACML or MPEG-21 Contracts Expression Language [Rodríguez15]. The MPEG-21 Media Contracts Ontology [Rodriguez16] defines an ontology to guide the generation of contracts as RDF, with a similar philosophy to that of the ODRL Ontology.

RDF documents instantiating the "Policy" class of the ODRL Ontology or using the XML or JSON syntaxes are called simply "ODRL Policies". The ODRL Ontology is already a formalization of the ODRL information model and vocabulary. The ontology of the version 2.1 consists of 1111 axioms with low complexity, but a comprehensive definition of each element (classes and relations) and a systematic definition of domains and ranges for the properties. Some ODRL concepts are represented as SKOS concepts ordered in SKOS collection. Reasoning with the ontology would be computationally inexpensive, but the usefulness of the possible reasoning tasks with the ontology is very limited.

The ODRL 2.1 Ontology is not the first ODRL Ontology and other ontologies had been proposed before [García05][Kasten10]. However, neither these ontologies nor the ODRL 2.1 Ontology directly supported any reasoning tasks of practical use. Other more generic rights ontologiesexist, claiming tocomprise the concepts of ODRL, with the ambition of facilitating interoperability. Thus, Delgado (2003) and Nadah (2007) have proposed ontologies as a bridge to make transformation between rights expression languages like ODRL and MPEG-21 REL, whereas Rodríguez (2013) underlined the similarities of seven policy languages with an ontology design pattern. Other alternative means of achieving interoperability do not require ontologies, as Guth did (2003) defining an abstract object model.

Some other formalizations of ODRL have been proposed with the purpose of determining whether a request is permitted given a set of policies and a certain history of events:we can name this task as theauthorisation decision.With that purpose, Gunter and Pucella had defined general logics for rights (2001 and 2002 respectively). Pucella then extended his work to model ODRL1.1 statements (2004) as formulas in a many-sorted first-order logic with equality,to determinewhether a permission was implied by a set of ODRL statements. Holzer et al. (2004) also enriched the authorisation decision modelling the dynamic aspects of licenses with finite-automata like structures (useful when the property of an asset is transferred, or when the number of plays is limited to a certain number of times). Chong et al. (2006) modelled licenses with multiset rewritingand logic programming (Prolog), including the ability to evaluate and merge licenses and to track the dynamic aspects of the rights evolution. Barth and Mitchell (2006) observed that the authorisation decision of a sequence of actions given a set of ODRL licenses is NP-complete because of the interval constraints, and proposed using propositional linear logic to grant efficient computability. Sheppard and Sfavi(2009) defined an algorithm for the authorisation decision with some of the most common ODRL elements, giving the pseudo-code for a virtual machine. Steyskal and Polleres (2015) defined an abstract syntax for expressing ODRL policies, where the dependencies among ODRL actions and the different conflict resolution strategies were explicitly considered in the rules for taking the authorisation decision.

Besides the problems of facilitating interoperability and making the authorisation decision, other problems of interest have been modeled with formalizations of ODRL. One of them is how to evaluate the compatibility and composition of licenses, useful when handling with differently licensed content or data. In this line, Gangadharan et al. (2007)proposed a matchmaking algorithm to analyze the compatibility of licenses and make license compositions; Jamkhedkarand Heileman (2008) showed how the combination of ODRL, CreativeCommons REL and the XrML (embryo of the MPEG-21 REL) licenses was possible with an abstract model and several rules. Villata and Gandon (2012) also defined a framework with algorithms to validate compatibility and to obtain composite licenses. Rotolo et al. (2013) defined a deontic logic system for the composition of licenses, with strict rules, defasible rules and defeater rules. More recent critics

It is evident that some policies can be used to grant automated access to resources. For example, verifying the execution of a payment can be automatically done. However, the satisfaction of some constraints cannot be digitally evaluated. Policies then play a double role, as automatable expressions in a computer system and as constracts with a certain legal value. Steyskal and Kirrane (2015) show how to use ODRL to specify access requests, data offers and agreements, distinguishing between enforceable and non-enforceable access policies, proposing an algorithm to auto-generate contracts for the latter.

In more recent efforts, de Vos et al. (2019) transforms ODRL expressions into Answer Set Programming to model policies and check compliance – specifically in the area of personal data processing, where ODRL has also been recently used (Esteves et al. 2021). Other profiles and initiatives have been proposed (Kim et al. 2020), on despite of several limitations found by Kebede at al. (2020).

In Fornara and Colombetti (2019) the ODRL 2.2 policy language has been extended in two directions. Firstly, by inserting in the model the notion of activation event, secondly, by considering the temporal aspects of obligations, permissions, and prohibitions (e.g. expiration dates and deadlines) as part of the application independent model of policies.

References

[Wieringa93] Wieringa, R. J., & Meyer, J. J. C. (1993). Applications of deontic logic in computer science: A concise overview. Deontic logic in computer science, pp. 17-40 John Wiley & Sons.
[Gunter01] Gunter, C. A., Weeks, S. T., & Wright, A. K. (2001, January). Models and languages for digital rights. In System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference on (pp. 5-pp). IEEE.
[ODRL02] Ianella, R. Open Digital Rights Language (ODRL) Version 1.1. Formerly available online.
[Pucella02] Pucella, R., &Weissman, V. (2002). A logic for reasoning about digital rights. In Computer Security Foundations Workshop, 2002. Proceedings. 15th IEEE (pp. 282-294). IEEE.
[XACML03] Anderson, A., Nadalin, A., Parducci, B., Engovatov, D., Lockhart, H., Kudo, M., ... & Moses, T. (2003). extensible access control markup language (xacml) version 1.0. OASIS.
[Delgado03] Delgado, J., Gallego, I., Llorente, S., & García, R. (2003, December). IPROnto: An ontology for digital rights management. In 16th Annual Conference on Legal Knowledge and Information Systems, JURIX (Vol. 106).
[Guth03] Guth, S., Neumann, G., &Strembeck, M. (2003, October). Experiences with the enforcement of access rights extracted from ODRL-based digital contracts. In Proceedings of the 3rd ACM workshop on Digital rights management (pp. 90-102). ACM.
[Pucella04] RiccardoPucella , Vicky Weissman. A formal foundation for ODRL, In Proc. of the Workshop on Issues in the Theory of Security (WIST’04)
[Wang04] Wang, X. (2004). MPEG-21 rights expression language: Enabling interoperable digital rights management. IEEE MultiMedia, 11(4), 84-87.
[García05] García, R., Gil, R., Gallego, I., & Delgado, J. (2005, July). Formalising ODRL semantics using web ontologies. In Proc. 2nd Intl. ODRL Workshop (pp. 1-10).
[Barth06] Adam Barth and John C. Mitchell. Managing digital rights using linear logic. In LICS ’06: Proceedings of the 21st Annual IEEE Symposium on Logic in Computer Science, pages 127–136,Washington, DC, USA, 2006. IEEE Computer Society
[Chong06] Chong, C. N., Corin, R., Doumen, J., Etalle, S., Hartel, P., Law, Y. W., &Tokmakoff, A. (2006). LicenseScript: a logical language for digital rights management. Annals of Telecommunications, 61(3), 284-331.
[Nadah07] Nadia Nadah, Melanie Dulong de Rosnay, Bruno Bachimont. Licensing Digital Content With A Generic Ontology: Escaping From The Rights Expression Language Jungle. ACM. ICAIL2007 - 11th international conference on Articial intelligence and law, Jun 2007, Stanford, United States. pp.65-69, 2007, Proceedings of the 11th international conference on Articial intelligence and law
[Gangadharan07] Gangadharan G.R., Weiss M., D’Andrea V., Iannella R. (2007) Service License Composition and Compatibility Analysis. In: Krämer B.J., Lin KJ., Narasimhan P. (eds) Service-Oriented Computing – ICSOC 2007. ICSOC 2007. Lecture Notes in Computer Science, vol 4749. Springer, Berlin, Heidelberg
[Jamkhedkar08] Pramod Arvind Jamkhedkar, Gregory L. Heileman. Conceptual Model For Rights. Proceedings of the 8th ACM workshop on Digital rights management Pages 29-38, 2008
[Sheppard09] Sheppard, N. P., &Safavi-Naini, R. (2009, November). On the operational semantics of rights expression languages. In Proceedings of the nineth ACM workshop on Digital rights management (pp. 17-28). ACM.
[Kasten10] Andreas Kasten and Rüdiger Grimm. Making the Semantics of ODRL and URM Explicit Using Web Ontologies. Virtual Goods, pages 77–91, 2010.
[Villata12] Serena Villata and FabienGandon. Licenses compatibilityand composition in the web of data. In The 2ndInternational Workshop on Consuming Linked Data.2012.
[Rodriguez13] Rodríguez-Doncel, V., Suárez-Figueroa, M. C., Gómez-Pérez, A., & Poveda-Villalón, M. (2013, October). License linked data resources pattern. In Proceedings of the 4th International Conference on Ontology and Semantic Web Patterns-Volume 1188 (pp. 84-87). CEUR-WS. org.
[Rotolo13] Antonino Rotolo, Serena Villata, and Fabien Gandon. A deontic logic semantics for licenses composition in the web of data. In Int’l Conf. on Artificial Intelligence and Law ICAIL, pages 111–120, 2013.
[Steyskal14] Simon Steyskal and Axel Polleres. Defining expressive access policies for linked data using the ODRL ontology 2.0. In Proceedings of the 10th International Conference on Semantic Systems, SEMANTICS 2014, Leipzig, Germany, September 4-5, 2014, pages 20–23, 2014
[Cabrio14] Elena Cabrio, Alessio Palmero Aprosio, and Serena Villata. These are your rights - A natural language processing approach to automated RDF licenses generation. In The Semantic Web: Trends and Challenges - 11th International Conference, ESWC 2014, Anissaras, Crete, Greece, May 25-29, 2014. Proceedings, pages 255– 269, 2014
[Ianella15b] R. Iannella, M. Steidl, S. Guth (eds). Open Digital Rights Language (ODRL) Version 2.1 – Common Vocabulary. Final Specification, W3C ODRL Community Group http://www.w3.org/community/odrl/vocab/2.1/
[Ianella15] R. Iannella& S. Guth& D. Paehler& A. Kasten (eds). Open Digital Rights Language (ODRL) Version 2.1 – Core Model. Final Specification, W3C ODRL Community Group. http://www.w3.org/community/odrl/model/2.1/
[McRoberts15] M. McRoberts, V. Rodríguez Doncel. Open Digital Rights Language (ODRL) Version 2.1 – Ontology. Final Specification, W3C ODRL Community Group http://www.w3.org/ns/odrl/2/
[Rodriguez15] Rodríguez, E., Delgado, J., Boch, L., & Rodríguez-Doncel, V. (2015). Media Contract Formalization Using a Standardized Contract Expression Language. IEEE multimedia, 22(2), 64-74.
[Steyskal15] Steyskal, S., &Kirrane, S. (2015). If you can't enforce it, contract it: Enforceability in Policy-Driven (Linked) Data Markets. In SEMANTiCS (Posters & Demos) (pp. 63-66).
[Steyskal15b] Steyskal, S., &Polleres, A. (2015, August). Towards formal semantics for ODRL policies. In International Symposium on Rules and Rule Markup Languages for the Semantic Web (pp. 360-375). Springer International Publishing.
[Rodriguez16] Rodríguez-Doncel, V., Delgado, J., Llorente, S., Rodríguez, E., & Boch, L. (2016). Overview of the MPEG-21 Media Contract Ontology. Semantic Web, 7(3), 311-332.
[DeVos19] De Vos, M., Kirrane, S., Padget, J., & Satoh, K. (2019, September). ODRL policy modelling and compliance checking. In International Joint Conference on Rules and Reasoning (pp. 36-51). Springer, Cham.
[Kebede20] Kebede, M. G., Sileno, G., & van Engers, T. (2020). A critical reflection on ODRL. Springer Lecture Notes Artificial Intelligence, AICOL2021, to appear.
[Kim20] Kim, J. M., & Chung, H. S. (2020). ODRL Ontology Extention Model and Prototype Design for the Specification of the Rights to use Digital Contents. Journal of Convergence for Information Technology, 10(1), 13-21.
[Esteves21] Esteves, B., Pandit, H. J., & Rodrıguez-Doncel, V. ODRL Profile for Expressing Consent through Granular Access Control Policies in Solid. To appear, proc. of the Workshop on Consent Management in Online Services, Networks and Things (COnSeNT) - co-located with IEEE European Symposium on Security and Privacy (EuroS&P 2021)
[Fornara19] N. Fornara and M. Colombetti. Using Semantic Web Technologies and Production Rules for Reasoning on Obligations, Permissions, and Prohibitions. AI Communications, vol. 32, no. 4, pp. 319-334, 2019.

Document Conventions

Prefix Namespace Description
odrl http://www.w3.org/ns/odrl/2/ [[odrl-vocab]] [[odrl-model]]
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [[rdf11-concepts]]
rdfs http://www.w3.org/2000/01/rdf-schema# [[rdf-schema]]
owl http://www.w3.org/2002/07/owl# [[owl2-overview]]
xsd http://www.w3.org/2001/XMLSchema# [[xmlschema11-2]]
skos http://www.w3.org/2004/02/skos/core# [[skos-reference]]
dcterms http://purl.org/dc/terms/ [[dcterms]]
vcard http://www.w3.org/2006/vcard/ns# [[vcard-rdf]]
foaf http://xmlns.com/foaf/0.1/ [[foaf]]
schema http://schema.org/ schema.org
cc https://creativecommons.org/ns# creativecommons.org
ex http://example.com/ns#