ODRL RDF expression

Hi everyone,

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).

I've attempted to keep things as close as I can to the originals, but have obviously balanced these against ease-of-use in RDF.

For the moment, both vocabularies are here (in Turtle format):

http://ptah.bencrannich.net/2013/UNSTABLE/vocab.ttl

http://ptah.bencrannich.net/2013/UNSTABLE/model.ttl

If you don't read somewhat badly-formatted Turtle, you could do worse than try my RDF browser to view them (though bear in mind that intra-vocab URIs won't resolve properly because they're not hosted at their own namespace locations):

http://lodscope.parthenon.org.uk/?uri=http%3A%2F%2Fptah.bencrannich.net%2F2013%2FUNSTABLE%2Fvocab

http://lodscope.parthenon.org.uk/?uri=http%3A%2F%2Fptah.bencrannich.net%2F2013%2FUNSTABLE%2Fmodel

I've also started working through the examples from the model:

http://lodscope.parthenon.org.uk/?uri=http%3A%2F%2Fptah.bencrannich.net%2F2013%2FUNSTABLE%2Fodrl-examples%2Ffigure-3.1

http://lodscope.parthenon.org.uk/?uri=http%3A%2F%2Fptah.bencrannich.net%2F2013%2FUNSTABLE%2Fodrl-examples%2Ffigure-3.2

[Discussion of the finer points of the RDF expression follows...]

Action, Scope, Operator, ConflictTerm and UndefinedTerm are all classes. The individual actions, constraints, scopes, etc., are instances of those classes. This does mean that the inheritance relationship between extract and extractWord (for example) isn't expressed, but the alternative is for them all to be classes and that makes things quite unpleasant elsewhere (and even worse when it comes to interoperability with terms defined by other vocabularies).

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.

(This may seem slightly perverse given the nomenclature, but it seems the sanest way to do it).

In other words:

Constraint
  name = count
  operator = lteq
  rightOperand = 1

... is expressed as an RDF instance in the form ...

a v:Constraint ;
  v:operator v:lteq ;
  v:count 1 .

The alternative would be to model the constraints as sub-classes of Constraint:

a v:Count ;
  v:operator v:lteq ;
  v:rightOperand 1 .

... and I'm really not convinced that having a property with a fixed name but whose value means different things according to the particular sub-class being used is a path to a long and happy life, so I settled for the former.

Similarly, functions (as well as target and output) are all a kind of property whose domain is any of Permission, Duty, or Prohibition. Given this, you might say:

<#some-permission> v:assigner <http://example.com/sony:10> .

<#a-duty> v:target <http://example.com/ubl.AUD0.50> .

Of course, things are slightly more complex if you need to apply a scope, but only in those cases. To do that, an intermediary "Party" is created which represents a scoped perspective on an entity:

<#some-permission> v:assignee [
  a m:Party ;
  m:scope v:allConnections ;
  rdf:value <http://example.com/somePerson>
] .

On the other hand, different kinds of Policy are modelled as subclasses of v:Policy (making it abstract), so'd you say something like

<#some-policy> a v:Offer ...

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:

<#some-policy>
  a v:Offer ;
  m:permission v:play ;
  m:prohibition v:reproduce ;
  ...

Obviously this only makes sense where the permission or prohibition being expressed is just an action. For more complex rules (e.g., those where there are constraints), it's of course still necessary refer to a m:Permission or m:Prohibition instance which contains the detail.

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.

I've not yet gone through the use-cases extensively nor picked through the ontologies with a fine-toothed comb, so it's entirely possible there are inconsistencies and gaps, but comments, questions, and so on, are of course more than welcome. I have projects for which it'd be really useful for me to be able to write ODRL terms as RDF, so I'm keen to get this right!

All the best,

Mo

--
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, 2 April 2013 14:28:33 UTC