SyntaxHighlighter

SyntaxHighlighter

Wednesday, April 22, 2015

Getting Topical at the IPTC Spring Meeting

Last summer, I became Chairman of the IPTC. My goal as Chair is to make IPTC better by improving the face-to-face meetings and improving how we communicate. So, how are we doing?

The IPTC is the global standards body of the news media. We provide the technical foundation for the news ecosystem. We recently held our Spring face-to-face meeting in New York, NY. Feedback from attendees was that the meeting was a success.

One of the things we did differently in this meeting was to put less emphasis on formal reports from the different standards initiatives within IPTC and more focus on active discussions, even when not connected to a particular standard.We held five topical sessions:
  • Taxonomies in news and the semantic exchange
  • Sports working session on Sports-in-JSON and new semantic tools in SportsML 3
  • HTML in NewsML-G2
  • Video metadata
  • APIs

Generally, the feedback on these was very positive. The main complaint was that sessions were held in parallel, whereas some people wanted to attend more than one topic session at the same time.

Also, taking advantage of our location in NYC, we were able to include a wider net of organizations and individuals in our meeting than might other wise attend - including Bloomberg, NPR, Business Wire, PR Newswire.
Overall, the meeting was much less formal than in recent years - we only had one vote (for a NewsML-G2 update). Hopefully, the meeting was a little friendlier and less intimidating for new attendees.

We are planning on building on this experience for our next face-to-face meeting 1st-3rd June in Warsaw. You can see some of the ideas that have been suggested already and please get in touch if you would like to suggest a topical session for either Warsaw or our October AGM in London.

Friday, April 17, 2015

More Concise ODRL and RightsML Expressions in XML using DRY Asset Patterns

DRY

Don't repeat yourself (DRY) is a much-loved principle of software engineering.

Essentially, the DRY principle states that you should strive to express any particular piece of information only once. This simplification typically improves maintainability and understandability. Systems which require you to repeat information are known by DRY-adherents as "WET" systems (for "We Enjoy Typing" or "Write Everything Twice").

DRY ODRL

In ODRL (and hence RightsML) every permission or prohibition refers to a particular asset.

When you have more than one permission or prohibition to express for a particular asset, this means you need to repeatedly refer to the same asset. How do you avoid repeating more than absolutely necessary to identify which asset the permission or prohibition constrains?

XML Linking

One solution for minimizing the amount of XML Markup is to use XML Linking. Here's an example where you identify an asset o:asset/@id=as1 and then use an @idref to refer to it in other permission or prohibition blocks.

<o:Policy xmlns:o="http://www.w3.org/ns/odrl/2/" type="http://www.w3.org/ns/odrl/2/Set" uid="http://example.com/policy:Z1XZ">
  <o:permission>
    <o:asset id="as1" uid="http://example.com/music:1234908" relation="http://www.w3.org/ns/odrl/2/target"/>
    <o:action id="ac1" name="http://www.w3.org/ns/odrl/2/play"/>
    <o:constraint id="c1" name="http://www.w3.org/ns/odrl/2/spatial" operator="http://www.w3.org/ns/odrl/2/eq" rightOperand="http://www.itu.int/tML/tML-ISO-3166:it"/>
    <o:party id="p1" uid="http://example.com/sony:10" function="http://www.w3.org/ns/odrl/2/assigner"/>
    <o:party id= "p2" uid="http://example.com/billie:888" function="http://www.w3.org/ns/odrl/2/assignee"/>
  </o:permission>

  <o:prohibition>
    <o:asset idref="as1"/>
    <o:action idref="ac1"/>
    <o:constraint name="http://www.w3.org/ns/odrl/2/spatial" operator="http://www.w3.org/ns/odrl/2/eq" rightOperand="http://www.itu.int/tML/tML-ISO-3166:fr"/>
    <o:party idref="p1"/>
    <o:party idref="p2"/>
  </o:prohibition>
</o:Policy>


Embed the ODRL inside the Asset Markup

The other thing you can do is to have markup for the asset itself (rnews:Article in the below example) embed the ODRL policy. This means that the ODRL is even more concise, as it only needs to refer to the ID of the asset.

<rnews:Article xml:id="item8HEX">
  <rnews:title>Allies are Split<rnews:title>
  <rnews:description>Rebel fighters take control...<rnews:description>

...

  <o:Policy xmlns:o="http://www.w3.org/ns/odrl/2/" type="http://www.w3.org/ns/odrl/2/Set" uid="http://example.com/policy:ABAABA">
  <o:permission>
    <o:asset uid="#item8HEX"/>
    <o:action name="http://w3.org/ns/odrl/vocab#distribute"/>
    <o:constraint name="http://www.w3.org/ns/odrl/2/dateTime" operator="http://www.w3.org/ns/odrl/2/gteq" rightOperand="2011-11-11"/>
  </o:permission>
</o:policy>

...

</rnews:Article>