Title: RE: [rights-examples] ln005: use case with markup for review
Please find some thoughts and comments listed below. Thx.
Bob
-----Original Message-----
From: DuCharme, Bob (LNG)
[mailto:]
Sent: Thursday,
August 15, 2002 2:05 PM
To: 'DeMartini, Thomas';
''
Subject: RE: [rights-examples]
ln005: use case with markup for review
>The other thing is
that the "play" right doesn't have
>any meaning without a resource.
Actually, all of my
scenarios (http://lists.oasis-open.org/archives/rights-examples/200207/msg00000.html
for natural language descriptions) refer to "this article" (except
for ln004, which implies it) because I was picturing the XRML license embedded
in the header of an article, perhaps in a NewsML-like wrapper. In this case,
the object of "play" would be implicit.
I suppose one could
assign some ID to the content within the wrapper and point to it from the
license to designate the object, and that would be a good use case to create
and mark up, but this leaves the general case addressed by ln004 unsolved. (I
realize that this started off as a discussion of ln005.) While pointing
to the resource from the license is obviously a valuable capability, the reverse,
or pointing to the license from the resource, is also very valuable when a
given license applies to many pieces of content. This is the point of ln004.
[rga] Are not all such “resource to license pointers”
from a logical perspective merely hints, in that once located, it would be the
license itself which authoritatively resolved whether or not it applied to the
resource in question?
This distinction is important, as the burden of making hints correct,
reliable, unambiguous, etc is much smaller than that involving authoritative statements.
You could express this
1-to-many relationship of the license to the resource(s) with a forAll, but implementing
it--following this collective "pointer" to all the digital
resources--would be painful for large enough n, especially if new ones are
continously arriving.
[rga] While you are correct, this is the sort of thing that
in analogy database routinely do as they construct indices on the data in their
tables as it dynamically changes. That is, it is very well understood territory,
at least conceptually.
In many situations, it
will make more sense for a system that receives a digital work to check it for
an included license, find a pointer to a given, stored license on the system,
follow that pointer, find out from the license what it's allowed to do with
that work, and to then act accordingly.
[rga] To me this would be fine and wonderful if it included
one additional step, namely a verification that the resources listed in the
license found in fact applied to the work in question.
In this case, there's no
need for the license to specify the content; the content specifies the license,
which specifies everything but the resource: the principal (class, more than
likely), the right, and the condition.
[rga] Equally well, it seems to me that we can keep the authoritative
specification where it is today (within the explicit resource inside the
license) and add hints in certain kinds of containers to perform the kind of
license location step you indicate. In contrast to a new notion of contextual,
implicit resource, keeping the authoritative specification where it is keeps
these concerns separate and clear, seeming at little expense.
>The reason resource
is optional is for rights like
>"walk" that don't have "direct objects".
Is there a specific place
in the XrML 2.1 spec that covers the optionality of resource regarding direct
object rights vs. the others?
This seems to be a result
of XrML's overall orientation toward consumer, end-user use of digital works. I
don't mean to imply that XrML is ignoring B2B use , but this issue may
point to an aspect of XrML that needs to be tweaked to help its use scale to
bigger consumers.
[rga] Actually there has been considerable historical focus
of XrML on non-DRM-oriented scenarios, particularly some large subset of the
B2B space. While of course there may be shortcomings that remain to be addressed,
it is indeed the case that many of these situations have well-considered
solutions within the existing framework.
One more possibility for
addressing this scenario is to just put the forAll in there anyway, just to
make it nice XrML, and implement the checking of digital rights for a content
work as described above, but this feels like shoehorning to me. It's putting
something in there, knowing that it's not needed for the system being implemented,
to fool the XrML processor into thinking that it's being used for the kind of
system that it was originally designed for. It would be better to broaden the
scope of the systems that XrML is designed for, because this would broaden its
applicability in the content industry, which would obviously be a good thing
for it as a standard.
thanks,
Bob DuCharme
Consulting Software Engineer, LexisNexis
Data Architecture, Editorial Systems and Content
Engineering
973-820-2324, 718-622-2484
