W3C home > Mailing lists > Public > public-odrl@w3.org > July 2012

Re: odrl-ISSUE-11: How to define anonymous policies [ODRL Version 2.0 Core Model (Public)]

From: Daniel Pähler <tulkas@uni-koblenz.de>
Date: Thu, 05 Jul 2012 14:08:41 +0200
To: public-odrl@w3.org
Message-ID: <1400635.UGUr2GZW5q@tulkastle>
On Thursday 05 July 2012 15:18:11 Renato Iannella wrote:
> On 3 Jul 2012, at 01:45, Daniel Pähler wrote:
> > The problem is that the Core Model defines that each Permission or
> > Prohibition must have at least one Asset. Changing something in the Core
> > Model that does not simply refine it but actually conflicts with it
> > should be done in a profile, I would say.
> 
> Another option maybe to allow the use of Set as the Policy Type and include
> the asset element with a null UID?

I would consider an asset with a null UID a bit of a hack – which does not 
mean that it might not be a very pragmatic solution.  An other solution could 
be to neither have the policy point to an asset nor the asset point to the 
policy, but have an intermediary, a kind of "meta-asset". The policy would 
only point to this one meta-asset, which could include a number of assets. New 
assets that are supposed to use the same policy could then dynamically be 
added to the meta-asset, which itself has a reference back to the policy.

If this were a mere programming problem, I think that my solution would work 
(without breaking the semantics of the Core Model, i.e., that each permission 
must point to an asset). In particular, it is similar to the way n:m-relations 
are handled in relational databases, where the problem is also "Should A refer 
to B or should B refer to A?".

But I'll admit that this solution is comparably complicated, and it might not 
fit well into the original IPTC use case.

Greetings,
Daniel
-- 
Dipl.-Inform. Daniel Pähler

Institute for IS Research
University of Koblenz-Landau
Universitaetsstrasse 1
D-56070 Koblenz
Fon +49-(0)261-287-2644
Received on Thursday, 5 July 2012 12:07:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 July 2012 12:07:46 GMT