Re: ODRL target/Dublin Core license/rights


On  2013-Jul-29, at 08:45, Renato Iannella <ri@semanticidentity.com> wrote:

> 
> On 29 Jul 2013, at 17:29, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
> 
>> i.e., where the ODRL policy fits the definition of a 'Rights document' or a 'License document' as defined by Dublin Core (and we should probably look at inserting the appropriate superclass relationships into the model accordingly), then consider it valid to use dct:rights or dct:license. In other situations, in the absence of any other obvious predicate with that directionality, one must use odrl:target instead.
> 
> Mo, how would you represent Scenario 3.11 [1] where we have multiple Assets?

Looking at that specific example, there are a couple of ways that you could do it, but I'd personally probably do...

<http://example.com/policy:881212>
 a policies:Set ;
 odrl:permission [
  odrl:action actions:index ;
  odrl:target <http://example.com/archive/2010> ;
  x:collection <http://example.com/x/database> .
 ] .

I think it's fairly reasonable to say that the reverse-direction relation (i.e., where we use dct:rights or dct:license) only unambiguously applies where it would be the target of *all* permissions and prohibitions which constitute the policy (you could be cleverer about it, but the axiom of diminishing returns applies given the additional burdens it places upon consumers of the data).

M.

-- 
Mo McRoberts - Analyst - BBC Archive Development,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D6, Media Centre, 201 Wood Lane, London W12 7TQ,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-----------------------------

Forwarded message 1

  • From: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
  • Date: Mon, 29 Jul 2013 08:44:52 +0000
  • Subject: Re: ODRL target/Dublin Core license/rights
  • To: Renato Iannella <ri@semanticidentity.com>
  • CC: "<public-odrl@w3.org> Group" <public-odrl@w3.org>
  • Message-ID: <06CFC7DF-95C8-4319-B422-5B1B01FB9D73@bbc.co.uk>
On  2013-Jul-29, at 08:45, Renato Iannella <ri@semanticidentity.com> wrote:

> 
> On 29 Jul 2013, at 17:29, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
> 
>> i.e., where the ODRL policy fits the definition of a 'Rights document' or a 'License document' as defined by Dublin Core (and we should probably look at inserting the appropriate superclass relationships into the model accordingly), then consider it valid to use dct:rights or dct:license. In other situations, in the absence of any other obvious predicate with that directionality, one must use odrl:target instead.
> 
> Mo, how would you represent Scenario 3.11 [1] where we have multiple Assets?

Looking at that specific example, there are a couple of ways that you could do it, but I'd personally probably do...

<http://example.com/policy:881212>
	a policies:Set ;
	odrl:permission [
		odrl:action actions:index ;
		odrl:target <http://example.com/archive/2010> ;
		x:collection <http://example.com/x/database> .
	] .

I think it's fairly reasonable to say that the reverse-direction relation (i.e., where we use dct:rights or dct:license) only unambiguously applies where it would be the target of *all* permissions and prohibitions which constitute the policy (you could be cleverer about it, but the axiom of diminishing returns applies given the additional burdens it places upon consumers of the data).

M.

-- 
Mo McRoberts - Analyst - BBC Archive Development,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D6, Media Centre, 201 Wood Lane, London W12 7TQ,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E

Received on Monday, 29 July 2013 08:45:50 UTC