Thursday, June 23, 2011

IPRM != DRM

Over the last year, I've been developing strategies that allow publishers to define and identify IP Rights. The big difference between digital rights management (DRM), and IP rights management IPRM is that DRM is about locking down assets to mitigate against piracy. IPRM is about identifying and calculating clearance to use assets for any given context, and enabling publishers to make informed decisions about using specific assets.

ODRL, or Open Digital Rights Language, is a well-established, robust, extensible XML markup designed specifically for this purpose. At it's core is the ability to define relationships between parties, assets, and permissions (i.e., print, display, execute). But it's real power is the ability to express complex permissions that include conditions and constraints. For example, "a licensee can use an asset in a printed book, but the print run is limited to 2,000 copies, and the asset creator must be given proper attribution and will receive two copies of the book prior to its release", or "the asset can be used in print, except that it can't be distributed in North Korea".

This is powerful, and gives publishers the capability to monitor and evaluate rights clearance while the product is in development. Using an XML Database and XQuery, it's relatively trivial to calculate clearances for all assets for a product and to display the information in a dashboard. Editors can monitor the progress of rights clearances against all assets and determine whether to acquire additional rights to use assets that haven't been cleared, or to use other assets instead. Publishers can also track asset usage to ensure that the proper royalties are paid. It also helps publishers in "what if" scenarios: they can easily determine the cost and feasibility of adapting a product for a different market, which will tell them how many of the existing assets are cleared for use in that market and how many remain that either need additional clearance or should be replace with other assets.

Another scenario we're working on is using ODRL for wholly-owned assets. Publishers frequently commission third parties to produce photos, images, and other rich media for which the publisher retains the rights to. They want to reuse these assets for obvious cost savings, however, they don't want to over-expose assets. Frequently, editorial teams are primarily focused on one project or program, and have little insight as to what others are doing, so it's quite possible that an image could be used by more than one product at the same time. Not that this is always a bad thing, but it can lead to over-exposure. Using ODRL to manage access to assets, using embargo dates and other usage information, editorial groups can quickly make informed decisions whether to use an asset or look for another.

Pretty cool stuff

Using DITA for Genealogical Data

I’ve been working on putting my family history together for the last few years.  Most of the genealogical applications have some pretty nice features, but none seemed to have all of the features I wanted.  I wanted the ability to manage all of the summary information and relationships (all applications do this), but also cross reference the factual data with individual biographies.  And, I want to be able to display the information in different ways and formats – not just the ones supported by any particular application.

I started looking at the format that most genealogy programs store the data into.  With few exceptions, they all use GEDCOM, or GEnealogical Data COMmunication.  The standard was developed by the Church of Jesus Christ of Latter-day Saints as a means of creating a portable data format to express information about individuals, families and sources (bibliography).

GEDCOM is line-delimited field format that identifies the start of a new record with the number 0.  Fields within a record are identified with an incremented number.  For example a first level field line would start with the number 1.  A subfield (e.g, the given name of a person’s full name) would start with the next highest number. The following is an example record for an individual

      0 @1@ INDI
    1 NAME Robert Eugene/Williams/
    1 SEX M
    1 BIRT
    2 DATE 02 OCT 1822
    2 PLAC Weston, Madison, Connecticut
    2 SOUR @6@
    3 PAGE Sec. 2, p. 45
    3 EVEN BIRT
    4 ROLE CHIL
    1 DEAT
    2 DATE 14 APR 1905
    2 PLAC Stamford, Fairfield, CT
    1 BURI
    2 PLAC Spring Hill Cem., Stamford, CT
    1 RESI
    2 ADDR 73 North Ashley
    3 CONT Spencer, Utah UT84991
    2 DATE from 1900 to 1905
    1 FAMS @4@
    1 FAMS @9@

 


Other than the line/sequencing delimiters, the data structures are pretty free form, and is parser dependent.  Even the field names, outside the common set supplied by GEDCOM are parser dependent.  So if you use one genealogy tool, it can understand these fields, but if you try to load it in another, it blows up.  Gah!  Add to that, GEDCOM just isn’t that great for handling rich content like pictures in a biography.


This sounds like a job for XML. 


So the first question I had to address is how to model this.  I’ve looked at some the of GEDCOM XML sites, and they suffer from the same problems as the text data structure do.  Just not enough rich data. 


The answer I came up with was to use DITA, which has several things going for it:



  1. I can easily mimic GEDCOM’s data structure with a specialized map
  2. I can extend the model to support other potentially valuable metadata
  3. I can easily model rich biographical content as a topic specialization
  4. DITA’s numerous linking mechanisms work well for the various types of links I would need:  internal references within a map, rel-tables, cross-references, external hyperlinks to third-party websites and content.

The first thing I did was to model and create a map specialization that mimics the GEDCOM data.  For the sake of brevity, I’ll show a sample of a specialized map.  If you want more information, ping me:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE familytree SYSTEM "file:/opt/dita/1.2/dtd1.2/genealogy/dtd/familytree.dtd">
<familytree>
    <title>Schmoe Family Tree</title>


    <individual id="I1" keys="I000001" gender="male">
        <vitals>
            <personname>
                <firstname>Joseph</firstname>
                <firstname type="nickname">Joe</firstname>
                <middlename>Aloysius</middlename>
                <lastname>Schmoe</lastname>
                <generationidentifier>III</generationidentifier>
            </personname>
            <birth>
                <date>
                    <day>1</day>
                    <month>1</month>
                    <year>1968</year>
                </date>
                <location>
                    <placename>The Stork Factory</placename>
                    <addressdetails>
                        <locality>Anytown</locality>
                        <administrativearea>Anystate</administrativearea>
                        <country>USA</country>
                    </addressdetails>
                </location>
            </birth>
        </vitals>
    </individual>


    <individual id="I2" keys="I00002" gender="male">
        <vitals>
            <personname>
                <firstname>John</firstname>
                <firstname type="nickname">Jack</firstname>
                <middlename>Michael</middlename>
                <lastname>Schmoe</lastname>


            </personname>
            <birth>
                <date><day>1</day><month>1</month><year>1948</year></date>
            </birth>
        </vitals>
    </individual>


    <individual id="I000003" keys="I000003" gender="female">
        <vitals>
            <personname>
                <firstname>Jane</firstname>
                <middlename></middlename>
                <lastname type="maidenname">Doe</lastname>
                <lastname type="marriedname">Schmoe</lastname>
            </personname>
            <birth>
                <date>
                    <day>1</day>
                    <month>1</month>
                    <year>1947</year>
                </date>
            </birth>
        </vitals>
    </individual>
   
    <family id="f1" keys="F1">
        <familymeta>
            <marriage>
                <date>
                    <day>1</day>
                    <month>1</month>
                    <year>1967</year>
                   
                </date>
            </marriage>



        </familymeta>
        <child keyref="I000001"/>
    </family>


    <familyreltable>
        <record>
            <indi>
                <personref keyref="I00001"/>
            </indi>
            <famc>
                <familyref keyref="F1"/>
            </famc>
            <fams/>
        </record>
        <record>
            <indi>
                <personref keyref="I00002"/>
            </indi>
            <famc/>
            <fams>
                <familyref keyref="F1"/>
            </fams>
        </record>
        <record>
            <indi><personref keyref="I00003"/></indi>
            <famc></famc>
            <fams>
                <familyref keyref="F1"/>
            </fams>
        </record>
       
    </familyreltable>


</familytree>