RE: [rights-examples] ln00x use case discussion

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Title: RE: [rights-examples] ln00x use case discussion

In as much as there is an "XrML approach", it doesn't seem too far off from the XrML approach at all.  I think what we're talking about here is how one might build a system, which XrML tries not to dictate.  What XrML does try to do is be self-contained in a way.  I don't know if "self-contained" is the right way to describe it, but what I mean is that if someone runs across a rights expression they should be able to read it without inspecting the entire system.  It seems if we don't have this constraint we're that much farther away from true interoperability.

That said, that doesn't mean that you have to indicate in each license every piece of content it applies to.  All it means is that you have to indicate that what you mean is that it applies to every piece of content that points at it.  Otherwise, how is anyone who doesn't know what you meant supposed to figure out what you meant just by looking at the rights expression?  A way to rewrite the grant you show below for use in a system like the one you describe might be to write this instead:

<grant>
        <forAll varName="referringContent">
                <mySystem:contentReferringToContainingLicenseId method="contentHeader"/>
        </forAll>
        <dcx:play/>
        <resource varRef="referringContent"/>
        <sx:territory>
                <sx:location>
                        <sx:country>US</sx:country>
                </sx:location>
                <sx:location>
                        <sx:country>CA</sx:country>
                </sx:location>
                <sx:location>
                        <sx:country>MX</sx:country>
                </sx:location>
        </sx:territory>
</grant>

(Anything in the US, CA, or MX can play any content whose header refers, by license id, to the license that contains this grant).  This way, you can achieve the functionality you describe while maintaining the self-contained-intent nature of the license.

---

Another interesting thing people have proposed (that you might be interested in) is the use of "resource classes".  In this instance, each resource indicates which resource class they are in.  Licenses are then written for "any resource" in a specific class.  In essence, the licenseId approach is an example of a resource class approach where the resource classes are defined by a particular license id.  You can expand this, though, to make a generic resource class id with the advantage being that you can later issue new licenses refering to that generic resource class without having to go find each resource and update it to include the new license id.  The way you would do this is similar to the example above but with a couple words after mySystem changed.

---

A still different approach might be to have each resource contain a URL where licenses could be found.  This is similar to the licenseId approach except that in this case the URI is specifically a location URL and not a license Id.  That means that at the location defined by that URL there could be a license at first and then a licenseGroup later and so on.

---

Which approach a system designer picks will depend on the requirements of the system they are designing.

&Thomas.

-----Original Message-----
From: DuCharme, Bob (LNG) [mailto:bob.ducharme@lexisnexis.com]
Sent: Tuesday, July 02, 2002 12:26 PM
To: 'rights-examples@lists.oasis-open.org'
Subject: RE: [rights-examples] ln00x use case discussion

(I attempted to quote the last one as concisely as possible to give context
to my comments without making this too long. ">>" starts my original
questions and ">" Thomas's responses.)

>>2. (ln004) Is there XrML markup to say "usage parameters of this
>>resource are described in the license with the ID 'c12345', whether
>>that license is expressed as XrML markup or as a hard copy contract"?

>This one is tricky, in a way.  Let us, for a moment, assume that we
>have a bunch of XrML licenses and English licenses floating around.
>The XrML licenses indicate inside of them what content they apply to.
>The same goes for the English licenses. 

Actually, it makes more sense for my purposes to turn this around: the XrML
licenses don't indicate what content they apply to; the content indicates
which licenses apply. This is what I was trying to express in my use case.

>Now, if somone knows what
>content they have, how do they figure out what licenses apply?

Because the content says which licenses apply, if only by specifying an ID
of the license. The license only specifies the right(s) and the
condition(s). Note that I didn't have any question about ln005--the
following seemed to work fine:

  <grant>

    <dcx:play/>

         <sx:territory>
           <sx:location>
                  <sx:country>US</sx:country>
                </sx:location>
           <sx:location>
                  <sx:country>CA</sx:country>
                </sx:location>
           <sx:location>
                  <sx:country>MX</sx:country>
                </sx:location>
         </sx:territory>

  </grant>

To sum up, I see the following as a viable model for what we need to do:

- a collection of licenses that pair up rights and conditions (with, I
suppose, some conditions describing classes of customers that users must
belong to in order to be granted the rights, perhaps using a principalClass)

- content that points at existing licenses, perhaps using the license
elements licenseId attribute.

Does this seem too far off from the general XrML approach to you?

thanks,

Bob

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>