[Odrl-version2] contracts/tickets and downstream rights

[Susanne Guth]

Stephane!

Thanks for your useful remarks. You are addressing crucial points.

After discussing this with Renato your issue probably falls into two
requirement categories 1.5 and 1.1:
 
Amongst other cases, with 1.5 ("Provide additional contract parties or third
parties") we want to address the case where one contract is including e.g.
seller, buyer, and a beneficiary party that is acting on behalf of the
buyer. For example, if a university buys access right to a commercial
library for their students. Here, students of the Vienna University may
access the library until end of year 2004. A corresponding future ODRL
instance could look like this:

<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/X.X/ODRL-EX"
			xmlns:o-dd="http://odrl.net/X.X/ODRL-DD">
  <o-ex:agreement>
    <o-ex:asset>
      <o-ex:context>
	<o-dd:dLocation>http://www.somelibrary.com/</o-dd:dLocation>
      </o-ex:context>
    </o-ex:asset>

    <o-ex:party party-type="rightsholder">
      <o-ex:context>
        <o-dd:name>Some Library LTD</o-dd:name>
      </o-ex:context>
    </o-ex:party>

    <o-ex:party party-type="consumer">
      <o-ex:context>
        <o-dd:name>Vienna University of Econ. & BA</o-dd:name>
      </o-ex:context>
    </o-ex:party>

    <o-ex:party party-type="beneficiary">
      <o-ex:context>
        <o-dd:role>Student at Vienna University of Econ. & BA</o-dd:name>
      </o-ex:context>
    </o-ex:party>
		
    <o-ex:permission>
       <o-dd:display>
        <o-ex:constraint>
	  <o-dd:datetime>
           <o-dd:end>2004-12-31T23:59:59</o-dd:end> 
          </o-dd:datetime>
	</o-ex:constraint>
      </o-dd:display>
    </o-ex:permission>
  </o-ex:agreement>
</o-ex:rights>

So, if a person can identify himself as a student of the Vienna University
he will get access to the library on the basis of the above contract. No,
additional tickets have to be issued. 

Maybe, here it is important to note that we have to distinguish between
different stages in a contract life cycle (please refer to "Toward a
Conceptual Framework for Digital Contract Composition and Fulfillment"
http://wi.wu-wien.ac.at/people/Guth/toward_contract_frmwrk.pdf). The
contract itself can be stated in an ODRL instance (Lifecycle phase: contract
conclusion) and tickets which are issued for consumption of rights
(Lifecycle phase: execution of rights) can also be issued as ODRL instances.
This probably does not require a new version of ODRL. Keeping track of how
many tickets have already been issued and executed would need the logic and
database of a DRM system.

The following ODRL examples show a contract and two tickets that are related
to each other. 

<?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:agreement>
    <o-ex:asset>
      <o-ex:context>
	<o-dd:uid>urn.someserviceprovider#service00999</o-dd:uid>
      </o-ex:context>
    </o-ex:asset>

    <o-ex:party party-type="rightsholder">
      <o-ex:context>
        <o-dd:name>Some ServiceProvider</o-dd:name>
      </o-ex:context>
    </o-ex:party>

    <o-ex:party party-type="consumer">
      <o-ex:context>
        <o-dd:name>Stephane v. H.</o-dd:name>
      </o-ex:context>
    </o-ex:party>
		
    <o-ex:permission>
       <o-dd:execute>
        <o-ex:constraint>
	  <o-dd:count> 2 </o-dd:count>
	</o-ex:constraint>
      </o-dd:execute>
      <o-ex:requirement>
        <o-dd:postpay>
          <o-dd:payment>
            <o-dd:amount currency="EUR">20.00</amount>
          <o-dd:/payment>
        </o-dd:postpay>
      </o-dd:requirement>
    </o-ex:permission>

  </o-ex:agreement>
</o-ex:rights>

Two tickets are issued. One ticket per one-time use of the resp. service.
Most likely digitally signed, with expiration date, etc. by the service
provider. Note that payment or rightsholder information is of no value
anymore. Both tickets would look like the following. Each time the a
customer wants to use the service he would have to provide one of his
(valid, not expired, not already used) tickets.

<?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:context>
     <o-dd:uid>urn:ssp/TICKET-ID#5234985jgaöfkjaoq5o</o-dd:uid>	
    </o-ex:context>

    <o-ex:asset>
      <o-ex:context>
	<o-dd:uid>urn.someserviceprovider.com#service00999</o-dd:uid>
        <o-dd:dLocation>urn.ssp.webservices#000999</o-dd:dLocation>
      </o-ex:context>
    </o-ex:asset>

    <o-ex:party party-type="consumer">
      <o-ex:context>
        <o-dd:uid>urn.ssp.user#shardeveld</o-dd:uid>
      </o-ex:context>
    </o-ex:party>
		
    <o-ex:permission>
       </o-dd:execute>
    </o-ex:permission>
</o-ex:rights>

Amongst other cases, with Requirement 1.1 (Provide improved next rights
(downstream rights)), we want to give the ODRL community a clear way of
dealing with rights that are passed along the value chain. Is your question
addressing this topic(, too)? (In your example, do you see the beneficiaries
as customers of the paying party, where the paying party is the consumer of
the content creator?)

So long
Susanne

P.S. I did not run the examples in a validator, please excuse typ-os.

> Furthermore, I believe we also discussed the different approach between
> contracts/agreements and
> a kind of ticketing system, where a contract is negotiated (maybe with a
> paying party?) and the
> rights are consumed by others (the beneficiaries) in the form of tickets.
> Or where a subscription is necotiated in the form of a contract, which
> contains the right to open
> 15 e-books in a year, and the actual choosing of one book to read is
> constructed as a ticket.
> Does point 1.5 cover this?
> 
> Stephane van Hardeveld
> VirtuosoMedia
> 

-- 
Susanne Guth
susanne at odrl.net
ODRL Initiative
http://odrl.net/S

+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl