[rights-examples] ln00x use case discussion

["DuCharme, Bob (LNG)" <bob.ducharme@lexisnexis.com>]

After working on some XrML markup to represent my use cases, I sent some
questions in a private e-mail to Thomas. I'm posting my questions and his
responses here so that we can continue the discussion on this mailing list.
I'll be posting my responses to his comments shortly.

Lines preceded by ">" show my original questions and comments. 

Bob

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>Now that I'm trying to do XrML versions of my own use cases, I have
>some questions. First, a few notes:
> 
>The xsd:annotation documentation in the schemas are very well done.
> 
>Xerces Java 2.0.1 didn't do a very good job of parsing the examples
>that I'm working on against the schemas, but I downloaded 2.0.2 today
>and it does much better. Its dom.ASBuilder utility is great for
>checking documents against schemas or even just checking the syntax of
>the schema itself.
> 
>For the purposes of my attempted markup, I just created a variation of
>the cx namespace called dcx (demo content extension) to check my
>examples to make sure that they parsed.

o.k.  i have also this morning created a schema that reflects some of the
most recent MPEG decisions to date.  if you can get by with dcx, though,
until July 26th, that would be great.
 
>xrml2core.xsd declares an element called "xml," but 2.3 of the XML
>recommendation reserves the use of any names beginning with XML. From
>an XML 1.0 viewpoint, I suppose you could say that the xrml2core name
>is actually spelled "r:xml", but it's something to keep in mind.

i remember checking this before but somehow thought it only applied to
attribute names (possibly because element default is set to qualified, as
you point out).  perhaps it makes sense to change the names to be more
environment-friendly.  if i forget, remind me to submit a CR once the CMP
gets approved.  or would you do the honor of the first one?

>(Numbers refer to the numbers assigned to each use case in an earlier
posting to the examples list.)
> 
>My first four questions:
> 
>1. (Use case ln001). If I want to say that all customers of customer
>class c10012 may have a particular right, what's the best way to do
>this? The XrML idea of the principal, according to the technical
>overview, "must be resolved to a single party."

Actually, you might read that as "single party of 4" or something like that.
The singleness of the party is only in that using the authentication means
of the principal the computer cannot distinguish the party from the party.
For instance, if the party is username bob.ducharme@lexisnexis.com, that is
a "single party" as far as the computer can tell.  If you share your
password with three different people, that is still one party.  Four people,
but one party.  Kinda weird, but the only way it works.  Hopefully one of
these days someone will come up with an authentication means by which there
are only one-person parties.  Retinal scans maybe?  ...if that's the case,
then maybe hopefully not, depending on where you stand on the ethics...
 
> An alternative would be to not specify a principal at all and to
>somehow express "customerClass="c10012" as a Condition, but the
>closest example I can find in the CG Example Use Cases document is
>4.10, in which a possessProperty element is contained by the same
>element as a sony:sonyClubMember element. Isn't there something more

(you mean less?) 

>general than Property but less 

(you mean more?) 

>general than coupling possessProperty with something we make up
>ourselves to express this?

Actually, the cool thing about possessProperty is that it works using the
XrML notion of equality.  What this means is that you can have an
implementation (that knows nothing about what foo:customerClass=c10012 means
(and might have even been written years before foo:customerClass was
invented)) still be able to successfully process those licenses by using
other possessProperty licenses which bind certain principals to that class.
 
Or maybe you are getting at the fact that it is perhaps a pain to write and
propogate (probably the bigger headache) a schema for each person who wants
to do something like customer class.  There have been several attempts at
defining a generic property such as securityLevel and group and subscription
and etc, but none seem to be truly generic.  One thing we might try is some
sx:class of type xsd:anyURI.  This way you can assign people to certain
classes using the class element and all you have to really do is come up
with a URI to indicate your class.  ?
 
>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 will be an important capability for us as we make the transition
>from manual enforcement of grant parameters (e.g. representatives of
>two parties hammer out a contract, tech guy on receiving end does
>whatever is necessary to enforce those parameters). In a transitional
>stage, before the sender specifies all parameters using XrML, some
>sort of ID would be assigned to the contract and content metadata
>would refer to it using that ID.

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.  Now, if somone knows what content they have, how
do they figure out what licenses apply?
 
The trivial example is a search through all of the licenses checking if each
one, in turn, applies and then returning all matches.  A more sophisticated
solution might be to index the licenses in a database-like fashion so that
one can more efficiently arrive at the list of licenses that apply by
running a query.  Another step might be to store the output of such a query
along with the content so that even the query doesn't have to be run.  The
advantage of this last step is greater speed; the cost is the list is no
longer dynamic as new licenses are created and old licenses expire.  And, as
you point out, another advantage of the last step is to aid transition.
 
Anyway, the reason I present it this way is to set up my answer to your
question "is there XrML markup to say 'usage parameters of this resource are
described in the license with ID "c12345"'".  At the license level, this
answer is "it is out of scope".  As you can see from the discussion above,
it is the XrML markup that says what resource the license applies to.  It is
an exercise in indexing that allows this information to be viewed most
efficiently from another direction.  (Relational databases are very useful
for this kind of thing, but are not required.)  Such indexing exercise can
chose to index English licenses as well as XrML licenses (there is no
constraint on such indexing); the result would be a way to look up all
licenses that apply.  And, if you identify the licenses with URL URIs in
your indexing, there is nothing wrong with updating an English license with
an XrML license at the same URL.
 
At the condition level, the answer is "sort of but not yet really".  If
you're interested, I can give you the "sort of" later, but its probably not
what you want anyway, so I won't explain it here.  Rather, I'll take a shot
at what I think you might be asking for and then say that we don't have it
yet, but that I don't see why we shouldn't have it in the future.  Anyway,
here goes:
 
If the transitional stuff you are talking about is not at the full license
level, but rather a hybrid of XrML permissions set against English
conditions, this can be done using a hypothetical new condition called
"EnglishConditions" which contains a bunch of free text.  The
Principal/Right/Resource arms of the grant can be in XrML to identify who
can do what to what, but all the terms and conditions are still in English.
 
<grant>
    <keyHolder licensePartIdRef="CompanyA"/>
    <mx:copy/>
    <digitalResource licensePartIdRef="TheText"/>
    <sx:EnglishConditions>Pay $1 per copy to the
author.</sx:EnglishConditions>
</grant>
 
and/or
 
<grant>
    <keyHolder licensePartIdRef="CompanyA"/>
    <mx:embed/>
    <digitalResource licensePartIdRef="TheText"/>
    <sx:EnglishConditions>The author is credited in the text of the work
into which this work is embedded.</sx:EnglishConditions>
</grant>
 
and/or
 
<grant>
    <keyHolder licensePartIdRef="CompanyA"/>
    <mx:edit/>
    <digitalResource licensePartIdRef="TheText"/>
    <sx:EnglishConditions>Spelling edits that do not change the meaning
only.</sx:EnglishConditions>
</grant>
 
>3. (ln003) I checked all the elements in xrml2core, xrml2cx, and
>xrml2sx that can substitute for r:condition (i.e. that specify it as a
>substitionGroup) and didn't see any that looked like candidates for
>linking an isPartOf relationship to a rendering condition. Do you have
>any suggestions?

MPEG has made significant progress in addressing these kinds of containment
issues.  An element they have come up with is diPartOf, which explains a
part of relation, but doesn't have quite the same nuances as what you are
looking for.  The difference between diPartOf and isPartOf is that diPartOf
only requires that, say, an image is part of something else.  There is no
requirement that the image actually be *viewed as part of* that something
else.
 
A little backround on "di".  Di is short for Digital Item, which is MPEG's
way of describing multi-resource media.  Take, for instance, and html page
that has an image.  It is possible to grant rights to play the image once.
It is also possible to grant rights to play the html page (without the
image) once.  Someone who wants to view the html page with the image inline
will have to use up both rights.  In some cases, this is actually what the
content owner intends.  In other cases, the content owner wants to specify
that playing the *Digital Item* (the combination of the html page and the
image) can only be done once (regardless of whether the user has "load
images" enabled that one time or not).
 
What MPEG hasn't yet addressed is a constraint requiring the html page to be
viewed in conjunction with the image.  The reasoning behind this goes as
follows.  It seems that the intent of requiring this is not so much to
require actually computer things to happen as require the user to perceive
something.  That said, many things stand in the way of the user perceiving
something.  For instance, perhaps someone's instant messaging software is
always-on-top the browser where the image is supposed to go.  Or, in the
case of video+audio, perhaps someone has their speakers turned off or not
connected to the sound card.  Or, perhaps the person is deaf.  In cases
where the reason for wanting the user to perceive something is to warn them,
it makes more sense to have a condition called "ConfirmWarning" or something
that allows the user's software to get that confirmation from the user
however the user can give it.  (For instance, it could be a popup with an
o.k. button, but if the user can't see, it might be a spoken prompt.)  In
cases where the reason is solely for presentation, it was deemed that the
Digital Item approach was enough.  While granting the right to play a
Digital Item (such as the html + image) doesn't require the parts to be
viewed together and in the presence of one another, the software that
processes Digital Items will know that they are intended to be one unit and
should make a reasonable effort to present them as such.
 
Another line of reasoning, also supporting the same conclusion, goes like
this: when someone has the right to play an image, the presentation may
involve the whole image or any part thereof.  Similarly with an audio
recording, a piece of text, or a video.  Thus, when we have composite media
such as html+image it stands to reason that the right to play the item means
that the presentation could be the entire item or any part thereof.  Since
the image is just one part of the item, there is no constraint that the
image cannot be played by itself.
 
All of that said, this explains why r, sx, and mx do not deal with this
problem.  If there is some group of people where the problem is of vital
importance (so much so to outweight the costs), then there should be nothing
in XrML preventing these people to get together and define what this problem
actually is and what it means to systems which support it.  For instance, a
simple solution to some problem might be a condition called something like
"presentedInEntirety".  When applied to an html page it means the browser
would have to put it up and scroll through it all for the user.  When
applied to an image, it means the viewer would have to put it up and scroll
through it for the user.  When applied to an item that consists of
html+image, it would mean the browser would have to put them up together and
scroll through them both.  I'm not familiar with a problem that has that
solution, but it is an example of a problem I might not know about.  Most of
the problems I've seen have eventually worked down to the solution MPEG has,
and I suspect that is the case here, but I'd need a fuller understanding of
the problem to be sure.
 
>4. (ln006) The renderer element "Identifies the device that can be
>used to render a work. Used with render rights" and has principal as a
>child element. Principal doesn't have any children, and the elements
>that can substitute for it are allPrincipals and keyHolder. How would
>I specify that a document can only be rendered if it is done so on a
>device of class dev001?

Lets suppose each device has a key and that we want to allow it only to be
rendered on one particular device.  Then the grant would look like this:
<grant>
    <keyHolder>
        <info>
            ...fill in user key here...
        </info>
    </keyHolder>
    <mx:play/>
    <digitalResource>
        ...fill in resource here...
    </digitalResource>
    <mx:renderer>
        <keyHolder>
            <info>
                ...fill in device info here...
            </info>
        </keyHolder>
    </mx:renderer>
</grant>
 
Now, if we want to do this for any renderer that authenticates with any key,
we use an unconstrained variable (lets call it "device") like so:
 
<grant>
    <forAll varName="device"/>
    <keyHolder>
        <info>
            ...fill in user key here...
        </info>
    </keyHolder>
    <mx:play/>
    <digitalResource>
        ...fill in resource here...
    </digitalResource>
    <mx:renderer>
        <keyHolder varRef="device"/>
    </mx:renderer>
</grant>
 
Now, if we want to constrain this only to devices with keys of class dev001,
we add the constraint on the variable, like so (using the hypothetical
sx:class element I mentioned earlier):
 
<grant>
    <forAll varName="device">
        <everyone>
            <sx:class>urn:someOrg:deviceClass:001</sx:class>
            <trustedIssuer>
                <keyHolder>
                    <info>
                        ...fill in here the key you trust to certify device
keys as belonging to this class...
                    </info>
                </keyHolder>
            </trustedIssuer>
        </everyone>
    </forAll>
    <keyHolder>
        <info>
            ...fill in user key here...
        </info>
    </keyHolder>
    <mx:play/>
    <digitalResource>
        ...fill in resource here...
    </digitalResource>
    <mx:renderer>
        <keyHolder varRef="device"/>
    </mx:renderer>
</grant>
 
or (equivalently) (if you prefer the prerequisiteRight style of constraining
the device):
 
<grant>
    <forAll varName="device"/>
    <keyHolder>
        <info>
            ...fill in user key here...
        </info>
    </keyHolder>
    <mx:play/>
    <digitalResource>
        ...fill in resource here...
    </digitalResource>
    <allConditions>
        <mx:renderer>
            <keyHolder varRef="device"/>
        </mx:renderer>
        <prerequisiteRight>
            <keyHolder varRef="device"/>
            <possessProperty>
            <sx:class>urn:someOrg:deviceClass:001</sx:class>
            <trustedIssuer>
                <keyHolder>
                    <info>
                        ...fill in here the key you trust to certify device
keys as belonging to this class...
                    </info>
                </keyHolder>
            </trustedIssuer>
        </prerequisiteRight>
    </allConditions>
</grant>
 
Hope this helps?
 
Thanks,
Thomas.