From stephane at virtuosomedia.nl Fri Oct 15 19:39:58 2004
From: stephane at virtuosomedia.nl (Stephane van Hardeveld)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] First requirements working draft
Message-ID: <065001c4b292$8e66d610$fea8a8c0@stephane>
Two small remarks on typos:
- The copyright statement points to http://odrl,net, should probably be
http://odrl.net
- in Goals: 'keep ODLR simple' should be 'keep ODRL simple'
Furthermore, I believe we also discussed the different approach between
contracts/agreements and
a kind of ticketing system, where a contract is negotiated (maybe with a
paying party?) and the
rights are consumed by others (the beneficiaries) in the form of tickets.
Or where a subscription is necotiated in the form of a contract, which
contains the right to open
15 e-books in a year, and the actual choosing of one book to read is
constructed as a ticket.
Does point 1.5 cover this?
Stephane van Hardeveld
VirtuosoMedia
From Susanne.Guth at gmx.net Fri Oct 15 17:53:46 2004
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2]
First requirements working draft issued, please review!
Message-ID: <8611.1097823226@www3.gmx.net>
To the ODRL version 2 working group and the ODRL interest list.
A first working draft of the document
Open Digital Rights Language (ODRL) Version 2 Requirements
has been published today at the ODRL Version 2 WG Web Page:
http://odrl.net/2.0/
The document results from the work in standardization groups (e.g. LTSC
REL), the ODRL Workshop 2004, and several publications that are discussing
ODRL.
Please send your comments, additional requirements, and critics to
susanne@odrl.net by the end of October. Any remarks will be appreaciated.
So long
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
From Susanne.Guth at gmx.net Mon Oct 18 15:23:49 2004
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] contracts/tickets and downstream rights
References: <065001c4b292$8e66d610$fea8a8c0@stephane>
Message-ID: <22008.1098073429@www14.gmx.net>
Stephane!
Thanks for your useful remarks. You are addressing crucial points.
After discussing this with Renato your issue probably falls into two
requirement categories 1.5 and 1.1:
Amongst other cases, with 1.5 ("Provide additional contract parties or third
parties") we want to address the case where one contract is including e.g.
seller, buyer, and a beneficiary party that is acting on behalf of the
buyer. For example, if a university buys access right to a commercial
library for their students. Here, students of the Vienna University may
access the library until end of year 2004. A corresponding future ODRL
instance could look like this:
http://www.somelibrary.com/
Some Library LTD
Vienna University of Econ. & BA
Student at Vienna University of Econ. & BA
2004-12-31T23:59:59
So, if a person can identify himself as a student of the Vienna University
he will get access to the library on the basis of the above contract. No,
additional tickets have to be issued.
Maybe, here it is important to note that we have to distinguish between
different stages in a contract life cycle (please refer to "Toward a
Conceptual Framework for Digital Contract Composition and Fulfillment"
http://wi.wu-wien.ac.at/people/Guth/toward_contract_frmwrk.pdf). The
contract itself can be stated in an ODRL instance (Lifecycle phase: contract
conclusion) and tickets which are issued for consumption of rights
(Lifecycle phase: execution of rights) can also be issued as ODRL instances.
This probably does not require a new version of ODRL. Keeping track of how
many tickets have already been issued and executed would need the logic and
database of a DRM system.
The following ODRL examples show a contract and two tickets that are related
to each other.
urn.someserviceprovider#service00999
Some ServiceProvider
Stephane v. H.
2
20.00
Two tickets are issued. One ticket per one-time use of the resp. service.
Most likely digitally signed, with expiration date, etc. by the service
provider. Note that payment or rightsholder information is of no value
anymore. Both tickets would look like the following. Each time the a
customer wants to use the service he would have to provide one of his
(valid, not expired, not already used) tickets.
urn:ssp/TICKET-ID#5234985jga?fkjaoq5o
urn.someserviceprovider.com#service00999
urn.ssp.webservices#000999
urn.ssp.user#shardeveld
Amongst other cases, with Requirement 1.1 (Provide improved next rights
(downstream rights)), we want to give the ODRL community a clear way of
dealing with rights that are passed along the value chain. Is your question
addressing this topic(, too)? (In your example, do you see the beneficiaries
as customers of the paying party, where the paying party is the consumer of
the content creator?)
So long
Susanne
P.S. I did not run the examples in a validator, please excuse typ-os.
> Furthermore, I believe we also discussed the different approach between
> contracts/agreements and
> a kind of ticketing system, where a contract is negotiated (maybe with a
> paying party?) and the
> rights are consumed by others (the beneficiaries) in the form of tickets.
> Or where a subscription is necotiated in the form of a contract, which
> contains the right to open
> 15 e-books in a year, and the actual choosing of one book to read is
> constructed as a ticket.
> Does point 1.5 cover this?
>
> Stephane van Hardeveld
> VirtuosoMedia
>
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/S
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
From Steven_Rowat at sunshine.net Tue Oct 19 04:24:24 2004
From: Steven_Rowat at sunshine.net (Steven Rowat)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2]
re: First requirements working draft issued, please review!
Message-ID:
Hello,
As requested by Ms. Guth, I am posting these responses to the V2
requirements (below, after the '++++++') to this ODRL working group. In
general my comments are a support for the existing V2 requirements; I have
merely gone into detail as to why I feel certain of them are particularly
important for the situation of an independent 'content creator' who wishes
to sell their own works digitally on the Internet.
The only requirement for this situation that concerned me as possibly
missing is the ability to easily use a (probably free) 'preview' of a
portion of the work as part of the sale situation; however Ms. Guth has
explained that this is possible as well; which is good, because I think
this would be an important capability of the system.
+++++++
Goals:
"Keep ODLR simple" is a typo error. Should be 'ODRL'!
Requirements:
1.1 Provide improved next rights (downstream rights).
Agreed. I strongly support 1.1 downstream rights for control over usage by
*content creators in particular*. To me, the idea that content creators can
have full control throughout the distribution is the exciting and
revolutionary part of the whole ODRL scheme, since it means that:
a) there will be less censorship by 'middlemen' (or women) - who are
usually corporate players with little interest in the content itself.
b) there will be less (unnecessary) profit removal by non-creators before
the content reaches the user; thereby allowing for fair return to the
creator. In many creative endeavours at present, this does not happen -
only the distributors get paid, not the creators. (This is not only unfair,
in the larger picture it distorts our social evolution mechanisms.)
1.4. Support contract negotiation.
This is extremely important, since content use may come in the form of
yearly subscriptions, use without copying, use with copying, fair use, use
with ability to modify the content, collaborative use, etc. etc. There
should be an easy way to set up a mechanism where the content creator can:
a) know clearly his or her options in these semantics;
b) set them easily;
and where the user can have the resulting choices easily displayed and easy
to respond to.
[UML may be useful here. See my comments about UML after point 6].
1.7. Provide a "NOT" expression.
This seems like an efficient mechanism in some cases. However, it may
a) run afoul of laws in certain jurisdictions; or
b) allow the user to make use of the content in ways that the creator or
other enabler of this expression never intended.
If these problems are addressed in its wording and semantics, though, I see
no reason why this shouldn't be rolled into the basic contract negotiations
described in section 1.4.
1.9. Provide an aligned constraint data model.
This seems like a good idea, especially if it will streamline integration
with other access systems during implementation.
2. Keep ODRL simple.
Strongly agreed. (Aside: point 1.9 is a good example of following this
rule). An example would be using plain language terms wherever possible.
The remarkable world-wide spread of HTML is due in no small part, in my
opinion, to the fact that it uses common language terms throughout.
Contrast with, say, Javascript, where cryptic symbols must be mastered.
Keep ODRL in the HTML tradition, as far as allowing anyone who uses a given
lanaguage as a whole (ie., English) to be able to understand and even
develop in the ODRL in their language. Thus content creators themselves
will be able to understand the language of ODRL; which makes sense if it is
to be the main vehicle for the sale of their works.
6. UML
UML was new to me, so I went quickly through Borland's excellent tutorial
(). Using UML seems
like a very good idea.
In fact, I find myself hoping for - expecting - that someone will produce a
UML software tool that will allow content creators to set their
permissions. The world is full of content creators who are not computer
literate, and the quickest way to integrate them into an internet
distribution system for their work will be to give them a *diagram*-based
tool for setting the copyright use and price permissions for their work.
If ODRL is already using UML, then it would be a short hop to having
software companies produce transparent software tools for creator use -
much like Dreamweaver or Adobe GoLive, say, are greatly accelerating the
ability of internet users to make HTML pages without actually writing code;
they merely drag and drop, etc.. In the same way, UML could function in
ODRL permission-setting, I envision.
Thanks again for your work, and hope this helps a little,
Best wishes,
steven rowat
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
web site:
mailto:sc@rowatworks.com
From renato at odrl.net Thu Oct 21 15:07:19 2004
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
Message-ID:
Here are some more requirements we need to consider:
1 - Offer/Agreement Model Only
The current model of only supporting Offers and Agreements
needs to be reviewed. There maybe cases where this is not
relevant and just a generic set of rights is only required
to be expressed. There is also the possibility of supporting
a "Request" which is from a Consumer to a Rights Holders.
2 - Exclusive Permission
At the moment a Permission can be stated to be ?Exclusive?
with the use of an attribute. This could be expressed using
a constraint or other means.
3 - ForEachMember Constraint
The forEachMember constraint allows members of entities to
be assigned individual constraints (using URI and id/idref).
This could be expressed via other mechanisms as well as
supporting other options (eg: any Member, one Member, all
members, etc).
4 - Condition Model
The current Condition model is under-utilised. It needs to be
reviewed with the new V2 data model.
5 - Revoke Model
The current Revoke model is under-utilised. It needs to be
reviewed with the new V2 data model to determine if it is still
required. Revoking licenses may only make sense in specific
implementations of trust models.
6 - Security Model
The current Security Model is very explicit. It needs to be
reviewed to determine if it is best to be more open with the
details being provided in community Profiles (eg OMA Mobile DRM).
7 - Containers Model
The current Containers model needs to be reviewed to see if
it is adequate and/or can be improved.
8 - Sequence Model
The current Sequence model needs to be reviewed to see if
it is adequate and/or can be improved.
9 - Linking Model
The current Linking model needs to be reviewed to see if
it is adequate and/or can be improved.
10 - Inheritance Model
The inheritance model is used in the OMA DRM specification.
It would be useful to review its use to ascertain if any
improvements/refinements are necessary.
11 - The WEMI Model
ODRL supports the Work/Expression/Manifestation/Item model
to describe layers of content (from the Library community).
It would be useful to review this to ascertain if any
improvements/refinements are necessary. It maybe better, for
example, to incorporate this with Inheritance and/or Linking
between assets.
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From stephane at virtuosomedia.nl Thu Oct 21 22:13:58 2004
From: stephane at virtuosomedia.nl (Stephane van Hardeveld)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] contracts/tickets and downstream rights
References: <065001c4b292$8e66d610$fea8a8c0@stephane>
<22008.1098073429@www14.gmx.net>
Message-ID: <007601c4b75f$0ffde490$2e00000a@vaiostephane>
> Stephane!
>
> Thanks for your useful remarks. You are addressing crucial points.
>
> After discussing this with Renato your issue probably falls into two
> requirement categories 1.5 and 1.1:
Thank you!
> Maybe, here it is important to note that we have to distinguish between
> different stages in a contract life cycle (please refer to "Toward a
> Conceptual Framework for Digital Contract Composition and Fulfillment"
> http://wi.wu-wien.ac.at/people/Guth/toward_contract_frmwrk.pdf). The
> contract itself can be stated in an ODRL instance (Lifecycle phase:
contract
> conclusion) and tickets which are issued for consumption of rights
> (Lifecycle phase: execution of rights) can also be issued as ODRL
instances.
> This probably does not require a new version of ODRL. Keeping track of how
> many tickets have already been issued and executed would need the logic
and
> database of a DRM system.
This is exactly what I meant. It seems appropriate to include some formal
notion of
the lifecycle to ODRL. Maybe even with an (optional) tag which reflects the
state this
agreement is meant for (e.g. contract proposal, contract conclusion,
fulfillment, consumption, downstream transfer), maybe as part of a Usage
Scenario
specialization.
This could of course be left to the DRM system without a reflection in the
ODRL,
since it has to keep track of the life-cycle anyway.
>
>
> urn.ssp.user#shardeveld
>
>
I suppose the uid of the consumer may relate this party to the consumer
Stephane van H.
of your example? Could this also be a beneficiary party, which has a
seperate agreement with the
consumer party in the original contract?
>
> Amongst other cases, with Requirement 1.1 (Provide improved next rights
> (downstream rights)), we want to give the ODRL community a clear way of
> dealing with rights that are passed along the value chain. Is your
question
> addressing this topic(, too)? (In your example, do you see the
beneficiaries
> as customers of the paying party, where the paying party is the consumer
of
> the content creator?)
Might be. It should be possible, for example, to offer a contract where one
buys an (anonymous?) ticket for an un-identified piece of music from a large
supplier of music, and pass this on to another party (the beneficiary). This
latter party may then exchange this ticket for a piece of music, providing
the
value of this ticket covers the value of this piece of music. (An electronic
coupon, so to speak).
> So long
> Susanne
>
> P.S. I did not run the examples in a validator, please excuse typ-os.
>
Regards,
Stephane
> > Furthermore, I believe we also discussed the different approach between
> > contracts/agreements and
> > a kind of ticketing system, where a contract is negotiated (maybe with a
> > paying party?) and the
> > rights are consumed by others (the beneficiaries) in the form of
tickets.
> > Or where a subscription is necotiated in the form of a contract, which
> > contains the right to open
> > 15 e-books in a year, and the actual choosing of one book to read is
> > constructed as a ticket.
> > Does point 1.5 cover this?
> >
> > Stephane van Hardeveld
> > VirtuosoMedia
> >
>
> --
> Susanne Guth
> susanne@odrl.net
> ODRL Initiative
> http://odrl.net/S
>
> +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
> Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
>
> _______________________________________________
> ODRL-Version2 mailing list
> ODRL-Version2@odrl.net
> http://lists.odrl.net/mailman/listinfo/odrl-version2
>
From stephane at virtuosomedia.nl Thu Oct 21 22:35:22 2004
From: stephane at virtuosomedia.nl (Stephane van Hardeveld)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
Message-ID: <002601c4b762$0d09f190$2e00000a@vaiostephane>
Hi,
> Here are some more requirements we need to consider:
>
> 1 - Offer/Agreement Model Only
> The current model of only supporting Offers and Agreements
> needs to be reviewed. There maybe cases where this is not
> relevant and just a generic set of rights is only required
> to be expressed. There is also the possibility of supporting
> a "Request" which is from a Consumer to a Rights Holders.
>
Agreed!
>
> 2 - Exclusive Permission
> At the moment a Permission can be stated to be ?Exclusive?
> with the use of an attribute. This could be expressed using
> a constraint or other means.
Yes, I tend to like solutions without attributes :-). Besides, exclusivity
is in itself a constraint, so why not express it that way?
> 3 - ForEachMember Constraint
> The forEachMember constraint allows members of entities to
> be assigned individual constraints (using URI and id/idref).
> This could be expressed via other mechanisms as well as
> supporting other options (eg: any Member, one Member, all
> members, etc).
This would be very useful
> 5 - Revoke Model
> The current Revoke model is under-utilised. It needs to be
> reviewed with the new V2 data model to determine if it is still
> required. Revoking licenses may only make sense in specific
> implementations of trust models.
If it is necessary, it could be implemented via a ticketing system. One
agrees to a contract during contract negotiation, and the consumption
takes place via tickets. If a revocation system is needed, this can be
accomplished by checking with a DRM Management system before
sending out a new ticket. Maybe it should be included in the usage
scenarios?
> 6 - Security Model
> The current Security Model is very explicit. It needs to be
> reviewed to determine if it is best to be more open with the
> details being provided in community Profiles (eg OMA Mobile DRM).
And ISMACrypt?
> 10 - Inheritance Model
> The inheritance model is used in the OMA DRM specification.
> It would be useful to review its use to ascertain if any
> improvements/refinements are necessary.
Maybe some specific inheritance models/specs may arise in the
usage scenario discussions
> 11 - The WEMI Model
> ODRL supports the Work/Expression/Manifestation/Item model
> to describe layers of content (from the Library community).
> It would be useful to review this to ascertain if any
> improvements/refinements are necessary. It maybe better, for
> example, to incorporate this with Inheritance and/or Linking
> between assets.
>
>
> Cheers
>
> Renato Iannella
> ODRL Initiative
> http://odrl.net
Regards,
Stephane van Hardeveld
From renato at odrl.net Fri Oct 22 16:44:24 2004
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
In-Reply-To: <002601c4b762$0d09f190$2e00000a@vaiostephane>
References: <002601c4b762$0d09f190$2e00000a@vaiostephane>
Message-ID: <6E53A36E-23ED-11D9-9F80-00306541C018@odrl.net>
On 21 Oct 2004, at 21:35, Stephane van Hardeveld wrote:
> Yes, I tend to like solutions without attributes :-). Besides,
> exclusivity
> is in itself a constraint, so why not express it that way?
Yes, we can model as an Constraint, but we need to also indicate that
the party is the *only* party with those rights.
>> 6 - Security Model
>> The current Security Model is very explicit. It needs to be
>> reviewed to determine if it is best to be more open with the
>> details being provided in community Profiles (eg OMA Mobile DRM).
>
> And ISMACrypt?
Does ISMACrypt use W3C XML Digital Signature and Encryption standards?
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From Susanne.Guth at gmx.net Fri Oct 22 17:24:11 2004
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] your reqs. OK?
References: <6E53A36E-23ED-11D9-9F80-00306541C018@odrl.net>
Message-ID: <3377.1098426251@www20.gmx.net>
Did I add your requirements OK?
http://odrl.net/2.0/WD-v2req-20041022.html
This document is not yet linked.
Susanne
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
From Susanne.Guth at gmx.net Fri Oct 22 17:25:37 2004
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
References: <002601c4b762$0d09f190$2e00000a@vaiostephane>
Message-ID: <7824.1098426337@www20.gmx.net>
Stephane!
Thanks for you valuable comments. Could you give me some references to
ISMACrypt?
Susanne
> > 6 - Security Model
> > The current Security Model is very explicit. It needs to be
> > reviewed to determine if it is best to be more open with the
> > details being provided in community Profiles (eg OMA Mobile DRM).
>
> And ISMACrypt?
>
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
From stephane at virtuosomedia.nl Fri Oct 22 19:08:25 2004
From: stephane at virtuosomedia.nl (Stephane van Hardeveld)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] your reqs. OK?
References: <6E53A36E-23ED-11D9-9F80-00306541C018@odrl.net>
<3377.1098426251@www20.gmx.net>
Message-ID: <007501c4b80e$4e6f33a0$fea8a8c0@stephane>
Yep.
Stephane
----- Original Message -----
From: "Susanne Guth"
To: "ODRL Version 2.0"
Sent: Friday, October 22, 2004 8:24 AM
Subject: [Odrl-version2] your reqs. OK?
> Did I add your requirements OK?
>
> http://odrl.net/2.0/WD-v2req-20041022.html
>
> This document is not yet linked.
> Susanne
>
> --
> Susanne Guth
> susanne@odrl.net
> ODRL Initiative
> http://odrl.net/
>
> +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
> Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
>
> _______________________________________________
> ODRL-Version2 mailing list
> ODRL-Version2@odrl.net
> http://lists.odrl.net/mailman/listinfo/odrl-version2
>
From stephane at virtuosomedia.nl Fri Oct 22 19:38:46 2004
From: stephane at virtuosomedia.nl (Stephane van Hardeveld)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
References: <002601c4b762$0d09f190$2e00000a@vaiostephane>
<7824.1098426337@www20.gmx.net>
Message-ID: <064401c4b812$8c0f94d0$fea8a8c0@stephane>
http://www.isma.tv/resources/isma2
http://www.isma.tv/resources/techspecs/
Unfortunately, you will need to become a member. It is not as open as one
would like...
As I am looking into it again (been a while) it is probably too focussed on
stream encryption.
It does say something about DRM, but is working together with MPEG4-IPMP.
>From their website:
"In developing these specifications, ISMA relies on open, established
standards and often proposes amendments to relevant standards bodies'
efforts that are still in development. The primary goal of ISMA is to
publish and promote systemic, end-to-end specifications that enable
cross-platform and multi-vendor implementations. The first ISMA
specification defines an implementation agreement for streaming MPEG-4 video
and audio over IP networks. The alliance has also recently published its
very first integration specification for digital rights management (DRM).
Ongoing work consists of interactive content, next generation audio/video
streaming specifications, and initiatives for home networking and enterprise
applications. "
Please, check it out, maybe it is not appropriate as example security model
at all.
Stephane
----- Original Message -----
From: "Susanne Guth"
To: "ODRL Version 2.0"
Sent: Friday, October 22, 2004 8:25 AM
Subject: Re: [Odrl-version2] More Requirements
> Stephane!
>
> Thanks for you valuable comments. Could you give me some references to
> ISMACrypt?
>
> Susanne
>
> > > 6 - Security Model
> > > The current Security Model is very explicit. It needs to be
> > > reviewed to determine if it is best to be more open with the
> > > details being provided in community Profiles (eg OMA Mobile DRM).
> >
> > And ISMACrypt?
> >
>
> --
> Susanne Guth
> susanne@odrl.net
> ODRL Initiative
> http://odrl.net/
>
> +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
> Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
>
> _______________________________________________
> ODRL-Version2 mailing list
> ODRL-Version2@odrl.net
> http://lists.odrl.net/mailman/listinfo/odrl-version2
>
From Steven_Rowat at sunshine.net Sat Oct 23 04:10:28 2004
From: Steven_Rowat at sunshine.net (Steven Rowat)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
Message-ID:
Greetings,
Renato wrote:
>1 - Offer/Agreement Model Only
> The current model of only supporting Offers and Agreements
> needs to be reviewed. There maybe cases where this is not
> relevant and just a generic set of rights is only required
> to be expressed. There is also the possibility of supporting
> a "Request" which is from a Consumer to a Rights Holders.
Agreed that both are important changes - I think; but to clarify: in the
"generic set of rights" expression situation, do you mean that, for
instance, there may be cases where the rights holder wishes to publish the
fact that anyone may use the work in certain ways, without needing to
interact (ie. invoke an Agreement)? For example, suppose I hold the
publishing rights to recordings by a musician who has died. I may, for
various reasons, decide to donate some forms of the rights play these
recordings into the public domain. Under the v 1.1 model, someone would
need to be in 'Agreement' with this - but this is not relevant in this
case, since I only need to publish the specific 'gifts' and the permission
structure for their use. Hence the model needs to be changed to support
this. Is this an example of what you mean? If so, I agree that it's
necessary for ODRL to support this in V.2.
>possibility of supporting
> a "Request"
This seems very important, since a major advantage of the Internet over
traditional media is that it has two-way capability. Certainly we ought to
enshrine some form of this capability at a core level of ODRL; and there
may even be more than one core form of 'Request'. For example, it may be
important to have the user be able to request things from either the
rights holder *or* the 'work' itself. That is, one type of Request is part
of the Agreement about using a work, and one is part of the work - in the
sense that the 'Request' may be part of an *interaction* with a work which
is itself a piece of software.
That last idea leads to other possibilities that may be outside the scope
of this particular section - I'm not sure - yet still it seems important to
recognize, somewhere in ODRL, that 'Requests' or some term analogous to it
could, with increasing use of video and audio chat software, become a very
interesting part of how information-flow interactions are carried on.
For example: suppose you and I are chatting over the internet using
video-conference software, and you're a Professor of Linguistics and I'm a
'language student'. It would be wonderful, and possibly revolutionary in
the higher-education field, if ODRL could handle the situation where the
student 'requests' (by asking a question), and your answer - spoken in
realtime or chosen by you from a list of pre-packaged 'answers' - is not
only viewed by the student, but downloaded automatically onto the student's
CPU, where they can peruse it at their leisure - but only in certain ways
(set by the permissions/constraints of the interaction). And of course as
part of the ODRL interaction, there would be a small payment by the student
before the Request would be answered. :-)
Or, as another example, someone who is offering counselling in a particular
area - say, divorce counselling - could be having an on-line discussion
with someone who is asking them questions; the questions could be Requests
which would only be answered as long as the appropriate duty (payment) is
fulfilled during the request process.
Are these possibilities covered by any part of ODRL 1.1 at present, or in
the projections for V 2? If not, perhaps they could be considered; I feel
that enabling these types of interactions for royalty or piece-pay (or
barter) interactions on the Internet could have useful and possibly
wide-ranging applications.
steven rowat
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
web site:
mailto:sc@rowatworks.com
From renato at odrl.net Mon Oct 25 12:33:55 2004
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
In-Reply-To: <064401c4b812$8c0f94d0$fea8a8c0@stephane>
References: <002601c4b762$0d09f190$2e00000a@vaiostephane>
<7824.1098426337@www20.gmx.net> <064401c4b812$8c0f94d0$fea8a8c0@stephane>
Message-ID:
On 22 Oct 2004, at 18:38, Stephane van Hardeveld wrote:
> Unfortunately, you will need to become a member. It is not as open as
> one
> would like...
You can download version 1.0 (just need to supply your email address).
V1 does not mention any of the W3C signature/encryption standards.
V2 is planned for release later this year.
At this stage, we should keep any ODRL security model based on
open standards...
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From Susanne.Guth at gmx.net Mon Oct 25 13:12:36 2004
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] contracts/tickets and downstream rights
References: <007601c4b75f$0ffde490$2e00000a@vaiostephane>
Message-ID: <24835.1098670356@www33.gmx.net>
>
> >
> >
> > urn.ssp.user#shardeveld
> >
> >
>
> I suppose the uid of the consumer may relate this party to the consumer
> Stephane van H.
> of your example? Could this also be a beneficiary party, which has a
> seperate agreement with the
> consumer party in the original contract?
Yes, exactly! And this makes already clear that the semantics of seller,
buyer, rightsholder, beneficiary must be clearly stated. Maybe, in my second
example (with contracts and tickets) it would have been more sensible if I
had chosen "beneficiary" for the party "urn.ssp.user#shardeveld".
...
> Might be. It should be possible, for example, to offer a contract where
> one
> buys an (anonymous?) ticket for an un-identified piece of music from a
> large
> supplier of music, and pass this on to another party (the beneficiary).
> This
> latter party may then exchange this ticket for a piece of music, providing
> the
> value of this ticket covers the value of this piece of music. (An
> electronic
> coupon, so to speak).
Yes, that is our plan. I will try to make this more clear in the requirement
1.5.
So long
Susanne
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/
Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD
++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++
From renato at odrl.net Wed Oct 27 13:35:28 2004
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:04 2007
Subject: [Odrl-version2] More Requirements
In-Reply-To:
References:
Message-ID:
On 23 Oct 2004, at 03:10, Steven Rowat wrote:
> Agreed that both are important changes - I think; but to clarify: in
> the
> "generic set of rights" expression situation, do you mean that, for
> instance, there may be cases where the rights holder wishes to publish
> the
> fact that anyone may use the work in certain ways, without needing to
> interact (ie. invoke an Agreement)?
Yes, for cases outside the stricter Offer/Agreement model.
> That last idea leads to other possibilities that may be outside the
> scope
> of this particular section - I'm not sure - yet still it seems
> important to
> recognize, somewhere in ODRL, that 'Requests' or some term analogous
> to it
> could, with increasing use of video and audio chat software, become a
> very
> interesting part of how information-flow interactions are carried on.
There is *potential* for this (at this stage) and with a more flexible
model
a community may develop a profile for this.
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net