[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [rights-examples] Notes from 8/13 con call
Present: Bob, Thomas, Hari, Parama. The following points were discussed in Tuesday's conference call. (Thanks to Parama for writing them out): - Need for examples that emphasized the "core" schema of XrML. While we understand that the core by itself may not be sufficient to cover an end-to-end business model, we should create more examples that demonstrate core features and capture "general" business models (such as super-distribution) which may apply to a variety of domains. Hari's examples are steps in this direction. - Along the same lines, Parama will go through the MPEG examples and extract some that illustrate the strength of the core. Some may need revision to de-emphasize the mpeg extension aspects and accentuate the core. We may also bring out another example that is "structurally" similar to the fleshed-out MPEG example but addresses another domain. This would demonstrate how the two marked-up examples are similar in their usage of the core concepts and differ only in domain specific extensions. As an aside, someone needs to go through the XrML cookbook/tutorial and get some examples out to accomplish the same. - Some question has been raised regarding the "asymmetry" of XrML licenses and what the implications are. It will be useful to describe an example that emphasizes mutual or bilateral or consensus-based or symmetric (not sure what the right word here is) agreement and show the licenses that capture this example. The point being, even if a single license itself can be viewed as asymmetric (issuer and issuee), a combination of licenses can cover the "symmetric" requirements. Hari brought up another angle on this issue: not enough people realize that, with regard to some piece of content (or any digital item/piece of information), a single party does not have to be either a license issuer or an issuee; the party can be both. Examples that demonstrate this will show people the wider possibilities for the role that a single party can play in a given license. - Licenses can contain "issue" and "obtain" rights. Whether we call these "meta-rights" or "meta-licenses," we need some examples that demonstrate the use of these language constructs. - Need for "separation of concerns." It will be worthwhile at some point now to look at the pieces that make up a system that uses rights languages to perform enforcement. Some of these pieces may be already in existence or standardized (e.g. SOAP for messaging). Even for those pieces that are yet to be standardized or remain undefined, or that are probably not in the scope of the RLTC (e.g. DRM systems), it is worthwhile to call them out and outline the precise scope of the RLTC. - Hari pointed out that people often bring up the lack of a "role" (or equivalent) construct in XrML. This is clearly not the case. The language has a much more powerful construct ("possessProperty") that when used with prerequisiteRight (or the shorthand "everyOne") can express roles. Essentially, possessProperty allows issuing licenses to "named" groups with dynamic (non-fixed) members. The membership of such groups can be changed by issuing or revoking licenses with the "possessProperty" right. It will be extremely useful to get some examples of roles and other such requirements and address these examples (using the licenses with the possessProperty right if called for). Not sure if we want to first get all the requirements and point to a canonical use case that captures the essence of such requirements. Bob's ln00x use cases include opportunities to demonstrate this, and he will work to incorporate this.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC