Re: ODRL RDF expression

Hi all,

I've updated the Turtle and RDF/XML according to the updates Renato pointed me at. Specifically:—

- odrlv:unit is a property in the domain odrlv:Constraint

- odrlv:license is an instance of odrlv:Action

I've *not* added a dataType property on Constraint as RDF literal datatypes should do the job here, I believe.

The eagle-eyed will note I'm using 'odrlv' and 'odrlm' as default/preferred namespace prefixes, this is mainly because single-letter prefixes stand such a great risk of clashes that everybody tends to avoid them in the spirit of being nice -- less important within ODRL/XML, but matters more in the context of RDF where you might expect ODRL statements to be mixed in with other kinds of information about an asset.

There are a few things that I'd like to tighten up, particularly around the range of particular properties (notably the constraint operands), but otherwise I *think* this is looking pretty good.

All the best,

M.

On Thu 2013-Apr-04, at 09:39, Mo McRoberts <mo.mcroberts@bbc.co.uk> wrote:

>
> On Thu 2013-Apr-04, at 05:09, Renato Iannella <ri@semanticidentity.com> wrote:
>
>> On 3 Apr 2013, at 00:27, Mo McRoberts <mo.mcroberts@bbc.co.uk> wrote:
>>
>>> I've made a first attempt at expressing the ODRL common vocabulary and core model as RDF (with a little — although not very much — OWL sprinkled over it for interop).
>>
>> Mo, great work, and thanks ;-)
>>
>>> [Discussion of the finer points of the RDF expression follows...]
>>>
>>> Constraint is defined as a class which consists of operator, rightOperand and status properties. However, the rightOperand property is intended to be abstract (i.e., not actually used in practice), and the various types of constraint are sub-properties of rightOperand.\\
>>
>> We have small update to the Constraint class [1] - we have added "dataType" and "unit" attributes.
>
> I suspect dataType can be handled "transparently" through typed literals for the right operand, while "unit" can be an additional property.
>
>> Also, for the Vocab [2], we have added a new "license" term.
>
> No problem, I can roll that in.
>
>>
>>> ... is expressed as an RDF instance in the form ...
>>>
>>> a v:Constraint ;
>>> v:operator v:lteq ;
>>> v:count 1 .
>>
>> That looks nicer.
>>
>>> Within the policy, I've defined the permission and prohibition properties to have a range of v:Action *or* m:Permission and m:Prohibition (respectively), to allow simplified expression. Thus, you can say:
>>
>> Great.
>>
>>> Finally, as will be evident in the examples, the relationship between a policy and an asset it relates to has been left quite "loose"; rather than have a concrete relationship between a policy and the asset, I've left this effectively undefined but employed the dct:license predicate (from the Dublin Core Metadata Terms) to relate the asset to the policy in line with fairly common practice elsewhere.
>>
>> So there is no property from the Policy to the Asset?
>
> Not directly — however, one can relate from a Permission or Prohibition to the Asset (e.g., using v:target), or express the reverse relationship using DC.
>
> M.
>
> --
> Mo McRoberts - Analyst - BBC Archive Development,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
>


--
Mo McRoberts - Analyst - BBC Archive Development,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D4, 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.
-----------------------------

Received on Tuesday, 9 April 2013 09:15:19 UTC