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

Hi Daniel

I would like to throw in the real world context of news distribution: each news agency - as the most agile creators of professional news items - distributes many hundred to many thousand news items per day. And the distribution speed is essential to the business success. If the IPTC would bring up a rights expression system which requires that a released story has to wait until it is integrated into a long list of assets and even if the waiting time is only a few seconds, I can tell you that such a system will not be accepted.

Therefore it is a big requirement for the news industry to have means of pointing from the asset to the corresponding policy.

What about this:
- define a new asset relation, in addition to "target" and "output" - call it "refTarget" = asset which references this policy.
- Then we could define that in this case the @uid may be left empty.
- if an empty @uid is not acceptable we could have a look at ODRL ISSUE-10: How to define a group of assets.
If something like "urn:newsml:reuters.com:*" is acceptable any news item issued by Reuters would fall into the range defined by this wildcard - and that's ok for the IPTC use case.

Best,

Michael


> -----Original Message-----
> From: Daniel Pähler [mailto:tulkas@uni-koblenz.de]
> Sent: Thursday, July 05, 2012 2:09 PM
> To: public-odrl@w3.org
> Subject: Re: odrl-ISSUE-11: How to define anonymous policies [ODRL Version
> 2.0 Core Model (Public)]
> 
> 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 13:20:29 UTC