OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

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 us, 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.

Bob DuCharme
Consulting Software Engineer, LexisNexis
Data Architecture, Editorial Systems and Content Engineering
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