ODRL Service (ODRL-S) Profile

Working Draft: 2 April 2008

This version:: http://odrl.net/Profiles/Services/WD-20080402.html
Latest version:: http://odrl.net/Profiles/Services/WD.html
Editor(s):: G.R. Gangadharan, University of Trento, Italy; Renato Iannella, NICTA, Australia

Abstract

This document describes the semantics of service licenses and how they can be represented using a Profile of the ODRL rights expression language.

Status of this document

This is the first public Working Draft of the ODRL Services (ODRL-S) Profile. It has been produced by the ODRL Services Working Group. This is a Working Draft for review by working group members and other interested parties. Comments on this document should be sent to editors and discussion of this document takes place on the public working group mailing list odrl-services@odrl.net archived at http://odrl.net/pipermail/odrl-services_odrl.net/.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress".

Publication as a Working Draft does not imply endorsement by the ODRL Initiative.

This document was produced under the ODRL Initiative WG Process and Procedures document.

1. Overview
2. Profile Description
3. Scenarios (Informative)
Appendix-A: Profile Semantics (Normative)
Appendix-B: Profile XML Schema (Normative)
Acknowledgements
References

1. Overview

The ODRL Services (ODRL-S) Profile working group is developing the semantics for licensing Service-Oriented Computing (SOC) services. The profile will address the core semantics for the licenses to enable services to be used, reused, and amalgamated with other services. By expressing the license terms in ODRL, greater features can be supported, such as automatically detecting conflicts in service conditions, and making explicit all requirements and conditions.

ODRL-S is designed as a complementary language to describe licensing clauses of a service in machine interpretable form. The salient features of ODRL-S are as follows:

ODRL-S unambiguously represents service licensing clauses (based on formalization of licensing clauses).
ODRL-S is simple yet powerful and fully extensible language.
ODRL-S can specify licenses at service level and service operation level.
ODRL-S can be used with any of existing service description standards and languages.
ODRL-S is developed as a completely compatible profile with ODRL for describing a service license.

2. Profile Semantics

This initial profile has been developed from research work and license requirements analysis of the SOC sector. See [GR1] and [GR2] for further details.

The core model behind licensing SOC services, shown in Figure 1 below, include:

Identifying the Asset via the unique service identifier.
Articulating new SOC-specific Permissions.
Indicating the Commercial terms of use.
Expressing the Warranties, Indemnities, and Limitation of Liability.
Indicating the evolution requirements for the Service.

Model

Figure 1 - ODRL-S Profile Model

2.1 Asset

The Asset is used to identify the Service via the UID element within the Context element. Any other Context element may be used to provide additional descriptive detail about the Service. It is highly recommended that the Version element be used to clearly articulate the version of the Service.

2.2 Permissions

The ODRL-S Profile defines three new permissions that are directly related to the types of uses of services in the SOC sector. These are:

Adaptation - refers to the right of allowing the use of service interface only (execution).
Composition - refers to the right of execution with the right of interface modification. Composition is dependent on the execution of services being composed.
Derivation - refers to the right of allowing modifications to the service interface as well as the implementation of a service. Derivation requires independent execution of the service

2.3 Constraints

The ODRL-S Profile incorporates the NonCommercialUse constraint from the [ODRL/CC] Profile. This element is used to ensure that a service is not used in any commercial environments or for commercial advantage.

2.4 Requirements

The ODRL-S Profile incorporates the Attribution Requirement from the ODRL Core Profile. This element is used to ensure that the use of a service is attributed to the owner. If any specific wording or statement needs to be used, it is recommenced that the Remark element be used.

The ODRL-S Profile incorporates the Payment Requirement from the ODRL Core Profile. This element is used to describe the financial terms and conditions. It is recommended that one of the three payment models (Prepay, Postpay, or Peruse) be specified.

The ODRL-S Profile incorporates the ShareAlike Requirement from the [ODRL/CC] Profile. This element is used to ensure that any derivative of this service must be licensed under the same terms as the original license.

2.4.1 Warranties, Indemnities, and Liabilities

The Warranties, Indemnities, and Liabilities (WIL) model defines warranties, indemnities and limitations of liabilities associated with services. A warranty is a promise regarding the description of services and their quality, as stated by the service provider. A indemnity is protection against loss or other burden. A liability is limiting the responsibility of the service provision.

The WIL Model is represented diagrammatically in Figure 2.

Model

Figure 2 - ODRL-S WIL Model

Warranties are further categorised into the following entities:

Performance: specifies elements relating to quality of services based on temporal dimensions, including:

Mean Response Time: the mean time between the moment a request is sent to the time that the response has been provided to the consumer.
Mean Process Time: the average time for processing a service.
Mean Latency: the average round-trip time between sending a request and receiving the response.
Mean Throughput: measure of the average amount of service that is provided.

Compliance: specifies a set of quality aspects of the service in conformance with the rules, the law, compliance with standards, and the established Service Level Agreement (SLA), including:
- Resolution Rate: the average time for resolving problems related to service provisioning.
Reliability: specifies a set of technical measures related to hardware and/or software configuration of services and the network connections between the service requesters and providers, including:
- Max Utilization: the performance measure of a service related by throughput and response time.
- Mean Availability Rate: the probability of the service being accessible.
- Mean SL Violation Rate: the mean occurrences of breach of SLA clauses (including violations by providers and consumers).
Monitoring: specifies measures that support management of services, including:

Down Time Frequency: the frequency at which a service provider verifies the availability of a service.

Indemnities are further categorised into the following entities:

Third Party Claims: represents the statement provided by the licensor to the licensee to protect against the claims of a third party of any infringements over the intellectual rights.

Limitation of Liability are further categorised into the following entities:

Provisioning: specifies measures that support the provision of services, including:

Network Errors: The licensor will not be liable for problems with the network
Infrastructure Errors: The licensor will not be liable for problems caused by the infrastructure.

2.4.2 Evolution

The Evolution Model specifies the details of modifications by future releases or versions. The Evolution Model is represented diagrammatically in Figure 3.

Model

Figure 3 - ODRL-S Evolution Model

Evolution is further categorised into the following entities:

Max Upgrades: specifies the allowed number of upgrades to a service before the license becomes invalid
Max Versions: specifies the allowed number of versions of a service before the license becomes invalid
Substitutable: indicates that the service can be substituted for by another similar service of same scope to which the licensee is allowed to use
Generic: indicates that the service can be replaced by a service of broader scope and the licensee retains the rights over the generic service.

3. Scenarios (Informative)

Generally a service license is associated with a service. However, a service could have several operations which might differ in their usage terms. It is very common in the field of SOC for a service operation or a set of operations to be offered for free in terms of cost, and to require payments for using another advanced operations.

3.1 License Associating a Service

In general, each service can be specified with a license describing the terms and conditions for the use of and access to the service. Consider a service license with the following terms and conditions (with matching XML line numbers).

The service and the version is identified (6-7)
The service can be composed with other services. (11)
The service requires attribution. (14)
The service costs 9.99 Euros per use of the service. (15-19)
The service provider describes the following warranties for the service:

Mean response time : 10 milliseconds (22)
Mean process time: 7 milliseconds (23)
Mean latency: 0.1 milliseconds (24
Mean service level violation rate : 0.1% (27)
Mean availability rate: 99.9% (28)
Resolution rate: 1 hour (31)

The service provider will defend the consumer from any action based on a claim that the use of the service in accordance with the given service license infringes intellectual rights of any third party. (34-36)
The service provider is not liable for any kinds of functional or non-functional errors in the infrastructure and networks of the service. (37-42)
The service provider offers the right to use the service up to three new versions. (44)
The service could be replaced by another service with broader scope in functionality (without affecting the existing functionality) by the service provider to which the licensee is allowed to use. (45)

These licensing clauses of a service are expressed using ODRL-S as follows:


 <?xml version=”1.0” encoding=”UTF-8”?>
 <o-ex:rights xmlns:o-ex=”http://odrl.net/1.1/ODRL-EX”
               xmlns:o-dd=”http://odrl.net/1.1/ODRL-DD”
               
  <o-ex:offer>
    <o-ex:asset>
      <o-ex:context>
        <o-dd:uid> urn:forex:service:currency-rate </o-dd:uid>
        <o-dd:version> 2.0 </o-dd:version>
      </o-ex:context>
    </o-ex:asset>
    <o-ex:permission>
     <sl:composition/>
   </o-ex:permission>
   <o-ex:requirement>
     <o-dd:attribution/>
     <o-dd:peruse>
       <o-dd:payment>
         <o-dd:amount o-dd:currency=”EUR”> 9.99 </o-dd:amount>
       </o-dd:payment>
     </o-dd:peruse>
     <sl:warranty> 
       <sl:performance>
         <sl:meanresponsetime> 10.0 </sl:meanresponsetime>
         <sl:meanprocesstime> 7.0 </sl:meanprocesstime>
         <sl:meanlatency> 0.1 </sl:meanlatency>
       </sl:performance>
       <sl:reliability>
         <sl:meanslviolationrate> 0.1 </sl:meanslviolationrate>
         <sl:meanavailabilityrate> 99.9 </sl:meanavailabilityrate>
       </sl:reliability>
       <sl:compliance>
         <sl:resolutionrate > P1H </sl:resolutionrate>
       </sl:compliance> 
     </sl:warranty> 
     <sl:indemnity> 
       <sl:thirdpartyclaims/>
     </sl:indemnity>
    <sl:limitationofliability>
      <sl:provisioning>
        <sl:networkerrors/>
        <sl:infrastructureerrors/>
      </sl:provisioning>
    </sl:limitationofliability>
     <sl:evolution> 
       <sl:maxversions> 3.0 </sl:maxversions>
       <sl:generic/>
     </sl:evolution> 
   </o-ex:requirement> 
  </o-ex:offer>
 </o-ex:rights>

3.2 License Associating Features

As the terms and conditions for using and accessing a service can also be associated in the level of service operations, we model operational level licensing by the concept of features in services. Each feature is an operation or a bundle of closely related operations that can be invoked by the service. The concept of features of a service are implemented in ODRL-S by using the Unit model of ODRL.

Consider a Financial Service whose features facilitate buying and selling of foreign currencies. The specific service offers two different features:

Daily Rate: returns the current currency valuation - averaged over the past 24 hours.
Current Rate: returns the current currency valuation.

Both features of the service are offered for composition (11).

However, for the Daily Rate feature, attribution is required (14-18). And for the Current Rate feature, a payment is required (21-28).

The above terms and conditions could be represented in ODRL-S as follows. Note the use of the ODRL Unit Constraint to indicate which feature of the service the requirement applies to.


 <?xml version=”1.0” encoding=”UTF-8”?>
 <o-ex:rights xmlns:o-ex=”http://odrl.net/1.1/ODRL-EX”
               xmlns:o-dd=”http://odrl.net/1.1/ODRL-DD”
               
  <o-ex:offer>
    <o-ex:asset>
      <o-ex:context>
        <o-dd:uid> urn:forex:service:currency-rate </o-dd:uid>
        <o-dd:version> 2.0 </o-dd:version>
      </o-ex:context>
    </o-ex:asset>
    <o-ex:permission>
     <sl:composition/>
   </o-ex:permission>
   <o-ex:requirement>
     <o-dd:attribution>
       <o-ex:constraint>
         <o-dd:unit o-ex:type=”urn:forex:service:dailyRate”/>
       </o-ex:constraint>
     </o-dd:attribution>
   </o-ex:requirement> 
   <o-ex:requirement>
     <o-dd:peruse>
       <o-dd:payment>
         <o-dd:amount o-dd:currency=”EUR”> 0.25 </o-dd:amount>
       </o-dd:payment>
       <o-ex:constraint>
         <o-dd:unit o-ex:type=”urn:forex:service:currentRate”/>
       </o-ex:constraint>
     </o-dd:peruse>
   </o-ex:requirement> 
  </o-ex:offer>
 </o-ex:rights>

Appendix-A: Profile Semantics (Normative)

Todo: List of new elements, identifiers, definitions, data types etc.

Appendix-B: Profile XML Schema (Normative)

Todo: XML Schema extension to ODRL Schemas

Todo: The file location of this XML Schema is: http://odrl.net/Profiles/Services/SL-10.xsd

References (Non-Normative)

[ODRL/CC] ODRL Creative Commons Profile. ODRL Specification/ 6 July 2005 <http://odrl.net/Profiles/CC/SPEC.html>

[ODRL] Open Digital Rights Language (ODRL), Version 1.1. <http://odrl.net/1.1/ODRL-11.pdf> Technical Specification, ODRL Initiative, August 2002

[GR1] Gangadharan, G.R., Weiss, M., D'Andrea, V., Iannella, R. Service License Composition and Compatibility Analysis. Fifth International Conference on Service-Oriented Computing (ICSOC07), Vienna, Austria, 17-20 September 2007.

[GR2] Gangadharan, G.R., D'Andrea, V., Iannella, R., Weiss, M. ODRL Service Licensing Profile (ODRL-S). 5th International Workshop for Technical, Economic and Legal Aspects of Business Models for Virtual Goods and the 3rd International ODRL Workshop. 11-13 October 2007, Koblenz, Germany.

Acknowledgements (Non-Normative)

This specification is the work of the ODRL-S Profile Working Group. The contributions of the Working Group members to this specification are gratefully acknowledged. Active participants in the Working Group include (by alphabetical order): Vincenzo D'Andrea, G.R. Gangadharan (WG Co-Chair), Renato Iannella (WG Co-Chair), Michael Weiss.