RE: ODRL RDF expression

Thanks for sending this, Mo.

If wonder if it might be a good idea to host this kind of discussion somewhere on the ODRL website? http://www.w3.org/community/odrl/ You might get a bit more engagement that way? (Lots of people on this email list will be experts in ODRL, but may not be experts in RDF...).

One of the reasons that I was interested in ODRL in RDF is because I want to be able to embed rights expressions for news content within binaries (such as photos). So, I had hoped that I could use an ODRL-in-RDF representation to embed within XMP http://en.wikipedia.org/wiki/Extensible_Metadata_Platform which is a subset of the RDF/XML syntax. As part of the IPTC's RightsML work http://dev.iptc.org/RightsML (to express permissions and restrictions for the news industry using ODRL) we experimented with embedding RDF within XMP. We concluded that it wasn't possible to embed arbitrary RDF within XMP. So, it caught my eye that the lodscope link that you sent offers to represent your Turtle as XMP:

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

So, maybe that ODRL in XMP isn't a dead end after all? Do you know how the lodscope is creating the XMP (or how I could find out more)?

Meanwhile, we've started to think that maybe ODRL in JSON might be a good way forward. Although JSON and RDF are not particularly similar syntaxes, it would be good to see if we can keep the two ODRL representation efforts loosely aligned.

Regards,

Stuart




-----Original Message-----
From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk] 
Sent: Tuesday, April 02, 2013 10:28 AM
To: public-odrl@w3.org
Subject: 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.
-----------------------------



The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this email. Thank you.
[IP_US_DISC]

msk dccc60c6d2c3a6438f0cf467d9a4938

Received on Wednesday, 3 April 2013 20:50:50 UTC