- From: Daniel Pähler <tulkas@uni-koblenz.de>
- Date: Thu, 05 Jul 2012 14:08:41 +0200
- To: public-odrl@w3.org
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 UTC