[Odrl-version2] Make it Simpler?
Steven Rowat
Steven_Rowat at sunshine.net
Thu Jan 18 09:20:35 EST 2007
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
More information about the Odrl-version2
mailing list