[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
|
Please find some thoughts and comments listed below. Thx.
Bob
-----Original Message-----
>The other thing is
that the "play" right doesn't have
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
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC