rights-examples message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [rights-examples] ln005: use case with markup for review
- From: "DuCharme, Bob (LNG)" <bob.ducharme@lexisnexis.com>
- To: "'DeMartini, Thomas'" <Thomas.DeMartini@CONTENTGUARD.COM>,"'rights-examples@lists.oasis-open.org'" <rights-examples@lists.oasis-open.org>
- Date: Thu, 15 Aug 2002 17:05:00 -0400
Title: 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. 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.
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. 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.
>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.
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
bob.ducharme@lexisnexis.com
973-820-2324, 718-622-2484
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC