[Odrl-version2] Make it Simpler?

[Steven Rowat]

Hi,

I have some added thoughts, also derived from reading the Jamkhedkar 
et al. paper.

Primarily, I would like to suggest that Jamkhedkar's analogy with the 
simple tuples at the core of an SQL database may be the place to 
start.

If the REL core can be made *very* simple, then a huge amount of 
'plug-ins' for middleware can be offloaded, and ODRL might be much 
more quickly/widely adopted.

What I thought about last night, in attempting to simplify this as 
much as possible, was how the creation of a 'new idea' or 'work of 
art' comes about: it is almost always the product of a 
analysis/synthesis thought in the brain of a single person. That 
person then makes an embodiment, a representation of it, in physical 
object form, in order to communicate the idea to others.

(Person) Creating --> created idea (object)

This is the key tuple, the relation between the Person (who may 
occasionally be a group; so we can use the term 'Party' to cover 
both), and the embodiment of their idea. This embodiment is in some 
medium, and when identified with a tag becomes a recognizable object 
or 'Work'. So we have:

Party - > Work

That's as simple as it gets, I think, and if ODRL did nothing more 
than allow XML expression of worldwide databases that listed each 
tuple of Party and Work (Einstein, Paper on Special Relativity), 
including contact address for Einstein, then middleware could 
conceivably furnish everything else.

However, I don't think we need to go that simple (almost, but not 
quite). The next step, which makes it a 3-tuple, would be:

Party -> Work -> User

The relation between Work and User is where the huge complexity lies, 
and the point of the Jamkhedkar et al. paper, as I see it, is that 
ODRL and Xrml have gone too far into trying to manage that relation. 
As others have indicated, stubs can be embedded on left-hand side of 
the 'Work -> User' relation to help in this management. However there 
is an unlimited number of such stubs that can be embedded. And these 
stubs are much more liable to change with technology and with 
jurisdiction (and with evolution of the Party's decisions) than are 
the original 'Party -> Work' 2-tuple. The original Party -> Work 
relation will generally last for a lifetime or lifetimes; whereas 
anything in the 'Work -> User' relation is liable to change; more 
change as we go further to the right.

So the trick is how far into that second relation we need to go. It 
occurs to me that, as part of the Core REL, we might provide one key 
'special stub': the Party can in advance specify certain basic 
decisions about use of their Work (free; sale; no copies; etc.), and 
this will facilitate quick formulation of middleware that will finish 
the relation - without having to resort to contacting the Party and 
negotiating, in many cases.

However, in a sense, even that stub is secondary and on a different 
level than the original 2-tuple. Everything in the relation between 
the 'Work' and 'User' is subject to context limitation, and will be 
only valid locally in time or place. The 'Party -> Work' is 
universally valid, can be accessed by any users of the second 
relation.

So, in sum, I suggest we start with specifying the 'Party' and 'Work' 
simple connection in a way that all conceivable parties can access 
and use, and when that is stable add a first stub into the 'Work -> 
Users' relation that expresses the simplest possible decisions that 
'Party' can make about how 'Work' can be used. Then gradually add 
more complex stubs for specific situations, doing the most general 
ones first. And if the language used to access the Core is formulated 
to permit it, perhaps most or all of these additional stubs can be 
written by middleware providers.

In other words, the proper field of the Core REL, which will be free 
and open source, will be information about the creator of a work 
(perons, group) and how to identify the work (object tag), and, to a 
limited degree, how the creator wishes the work to be used. Any 
actual implementation of a mechanism to distribute the work to other 
people will be developed separately from this, and can be either free 
or not free, depending on the decisions of the people doing the work 
to create the required mechanisms.

There!  All solved.  ;-)

Anyway, if you got this far, thanks for reading it. :-)


Steven Rowat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20070117/b2fab72f/attachment.html