Authoritative Opinion

PBCore 2.0: What I’d like to see

Sun, 07 Feb 2010 19:29:36 +0000

This is a short writeup of things I would like to see present in PBCore 2.0, which is currently in progress. It reflects my own personal opinions, etc.

One of the biggest challenges that PBCore 2.0 will face is determining how all-encompassing a standard it should be. Media organizations create a large variety of assets through diverse mechanisms for a wide range of purposes with any and all possible skill sets and technologies. Billed as the metadata standard for public broadcasting, it probably needs to respond to everyone’s needs and avoid requiring the impossible or limiting the foreseeable. It is for this reason I believe the most important thing PBCore 2.0 can do is provide a structure and framework for metadata without proscribing “the one true way”. To do this, PBCore 2.0 must be flexible, and more importantly, extendable if it is going to succeed.

These ideas probably fall outside “core” PBCore-compliance, but would enhance the descriptive power of the schema. All it would take are two considerations during the development of PBCore 2.0: a permissive data model and (more importantly) a system and place to document and describe standard extensions, best practices, and implementations.

One of the biggest strengths of PBCore 1.x, as I’ve written earlier, is the vast data dictionary that is the combination of a number of siloed applications full of current data. In PBCore 2.0, I truly hope due consideration is given to linked data and semantic ontologies to provide an easy way for an organization or individual to supplement a core vocabulary with a purpose-driven vocabulary for describing assets (the EBU’s P-META classification schemes have taken the first tentative step into this realm and are well worth a look) . This could be done as simply as providing URL-based references to data dictionary values, e.g.:

...

RDF Schema
wikipedia.org

...

This system could be easily extended (in a standardized way) to provide data dictionary descriptions, relational information (sameAs, parentOf, etc) and more, while allowing some level of basic compliance that can ignore the extension.

Other extensions to the schema are probably more complex and would require the PBCore 2.0 schema to be permissive, rather than restrictive. One important (and I’d argue, essential) example of this is temporal + spatial media fragments, which could allow a system to describe, in some level of detail, fragments of an asset. This could be represented like:

...

RDF Schema


...

...

...

(obviously the semantics, describing multiple instantiations, and other issues would need to be worked out..)

I’d like to take this a step further and develop a systematic way of embedding other schemas (presumably designed for describing objects and ideas outside of the core focus of PBCore, such as people and entities, rights metadata, and provenance). By developing some best practices, this could be done in a discoverable and standard way, maybe something like:

...

    Chris Beer

   Chris Beer
   Male
   Mr
   
 
    Rabble-rouser

...

Tools that don’t understand FOAF should be encouraged to ignore these additions, but they provide a rich method of extending the schema in a decentralized and flexible manner.

Again, I’m not calling for the inclusion of advanced (and likely, complicated) features into core PBCore compliance, just hoping that in developing a standard for the future, it remains flexible and extendable to meet the needs of all users while being accessible to all.

Unlike

Open source happenings

Wed, 03 Feb 2010 02:18:49 +0000

Just some quick notes:

I got a patch into FITS to add some basic video metadata extraction. I’d like to take it further to ensure support for the formats that exiftool supports, but it’s a good start.
Today I pushed out a first release of ave-sync, a media/xml synchronization tool. Also a good start, and should be a starting place to play with the w3c FileAPI in Firefox 3.6.
XForms applications are painful to write, but probably a good choice for XML-based workflows.. more on that later..

A Fedora in a Pairtree

Mon, 18 Jan 2010 14:13:05 +0000

The California Digital Library (CDL) has released a number of exciting micro-services specifications for digital libraries. The Fedora repository from DuraSpace takes an opposite approach and has a monolithic applications comprised of a number of modules. With the modular approach, it should be possible to slip micro-services under the hood of Fedora easily.

Here is a first attempt at implementing the Pairtree filesystem hierarchy for Fedora:

package fedora.server.storage.lowlevel;

import java.io.File;
import java.util.Map;

import fedora.server.errors.LowlevelStorageException;

/**
 * @author Chris Beer
 */
class PairtreePathAlgorithm
        extends PathAlgorithm {

    private final String storeBase;

    private static final String SEP = File.separator;

    public PairtreePathAlgorithm(Map configuration) {
        super(configuration);
        storeBase = (String) configuration.get("storeBase");
    }

    @Override
    public final String get(String pid) throws LowlevelStorageException {
        return format(pid);
    }

    public String format(String pid) throws LowlevelStorageException {
        String pt = to_pairtree(pid);
		return storeBase + pt + "obj" + SEP + pid;
    }

    private String to_pairtree(String s) {
		String pt = SEP;
		String src = escape(s);

		int i = 0;
		while(i < src.length()) {
			pt += src.substring(i, i+2) + SEP;
            i+= 2;
		}

		if(i < src.length()) {
			pt += src.substring(i);
		}

		return pt;
    }
    private String escape(String s) {
		/*
		 Fedora PIDs do not support non-visible ASCII or the characters below,
		 so we skip hex encoding:
		 "   hex 22           <   hex 3c           ?   hex 3f
		 *   hex 2a           =   hex 3d           ^   hex 5e
		 +   hex 2b           >   hex 3e           |   hex 7c
		 ,   hex 2c
		 */
		return s.replace("/", "+").replace(":", "+").replace(".", ",");
    }
}

jQuery and SVG (and inline SVG)

Wed, 13 Jan 2010 19:45:06 +0000

If you’re using Keith Wood’s great jQuery SVG plugin, you may find that the .css() function doesn’t work on SVG elements, as in:

var elem = $('#test');
if (elem.css('display') == 'none') {
    elem.css('display', '');
}

will generate an error when CSS properties are written, but not when they are read. To address this, add this code to jquery.svgdom.js:

/* Support CSS on SVG nodes. */
var origCSS = $.fn.css;
$.fn.css = function(name, value, type) {
	if (typeof name === 'string' && value === undefined) {
		var val = origCSS.apply(this, [name, value, type]);
		return (val && val.baseVal ? val.baseVal.valueAsString : val);
	}
	var options = name;
	if (typeof name === 'string') {
		options = {};
		options[name] = value;
	}
	return this.each(function() {
		if (isSVGElem(this)) {
			for (var n in options) {
				this.style[n] = (typeof options[n] == 'function' ? options[n]() : options[n]);
			}
		}
		else {
			origCSS.apply($(this), [name, value, type]);
		}
	});
}

I make no guarantees that it works on all platforms or browsers, but I mimicked the way Keith implemented .attr() for SVG elements, using the style attribute instead, so it hopefully has similar levels of portability. So far it works for me in Firefox 3.5 and Chrome 3.0. I'm going to guess that it works in Safari, because old code that used the style attribute worked there as well. No idea about IE, because my SVG doesn't load in that to begin with...

In addition to this, I needed to use the plugin to modify existing inline SVG, which seemed daunting given that the plugin normally created its own SVG canvas to render on. However, by hacking together a few calls to some of the internal functions I was able to get a jQuery SVG Wrapper with which I could call methods such as circle(), etc.:

var theDiv = $("#svg-container-div")[0];
$.svg._afterLoad(theDiv, $("#svg-root-element"), {});
var svgRoot = $.svg._getSVG($("#svg-container-div"));
var svgDoc = $("#svg-root-element");
svgRoot._svg = svgDoc[0];
svgRoot.circle(svgDoc[0], 270, 150, 25, {'id' : 'testcircle', 'fill' : "#ffffff", 'stroke' : '#ff0000'});

I'm not sure that this method of doing things is entirely acceptable as far as using the plugin correctly, but for me it successfully modified the DOM and I was able to reference the created elements without incident afterwards. At this point there was one last thing that I wanted to change about the plugin: when creating an SVG element I needed to specify a DOM element, not a jQuery wrapper. Usually this just means that the jQuery wrapper must be de-referenced to get the node, i.e. svgDoc[0] above, but I would get annoyed having to remember to add the array de-reference, so I modified jquery.svg.js again, this time changing the definition of _args, which handles argument decoding for all of the svg functions:

_args: function(values, names, optSettings) {
		names.splice(0, 0, 'parent');
		names.splice(names.length, 0, 'settings');
		var args = {};
		var offset = 0;
		var vOffset = 0;
		if (values[0] != null && (typeof values[0] != 'object' || !values[0].nodeName)) {
			if (!(values[0].jquery && values[0][0].nodeName)) {
				args['parent'] = null;
				offset = 1;
				vOffset = 0;
			}
			else {
				args['parent'] = values[0][0];
				offset = 1;
				vOffset = 1;
			}
		}
		for (var i = 0; i < values.length; i++) {
			args[names[i + offset]] = values[i+vOffset];
		}
		if (optSettings) {
			$.each(optSettings, function(i, value) {
				if (typeof args[value] == 'object') {
					args.settings = args[value];
					args[value] = null;
				}
			});
		}
		return args;
	},

This should provide the same behavior but allow the results of $(selector) to be supplied directly as the first argument to any SVG drawing methods (circle, rect, etc.), but only the first of these will be painted to, which is most useful when selecting an id, not a class. In addition the previous method of directly supplying an SVG DOM element will still work, as will falling back to using the default internal reference that is established when the SVG canvas is created.

Unlike

Compiling mod_h264_streaming for lighttpd

Tue, 08 Dec 2009 15:01:02 +0000

In compiling the mod_h264_streaming module for lighttpd on Mac OS 10.4 (Tiger), I hit a few snags following these directions.

From the directions, the first half went smoothly:

wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.25.tar.gz
tar -xvzf lighhttpd-1.4.25.tar.gz
cd lighttpd-1.4.25
wget http://h264.code-shop.com/download/lighttpd-1.4.18_mod_h264_streaming-2.2.0.tar.gz
tar -zxvf lighttpd-1.4.18_mod_h264_streaming-2.2.0.tar.gz
cp lighttpd-1.4.18/src/moov.* src
cp lighttpd-1.4.18/src/mod_h264* src

add these lines to src/Makefile.am around line 266:
lib_LTLIBRARIES += mod_h264_streaming.la
mod_h264_streaming_la_SOURCES = mod_h264_streaming.c moov.c
mod_h264_streaming_la_LDFLAGS = -module -export-dynamic -avoid-version -no-undefined
mod_h264_streaming_la_LIBADD = $(common_libadd)

./autogen.sh
./configure --prefix=/opt/local

make

At this point, I ran into an error with the plugin:

[...]
moov.c:77:22: error: byteswap.h: No such file or directory
moov.c: In function 'byteswap16':
moov.c:96: warning: implicit declaration of function 'bswap_16'
moov.c: In function 'byteswap32':
moov.c:105: warning: implicit declaration of function 'bswap_32'
moov.c: In function 'esds_read':
moov.c:1941: warning: unused parameter 'size'
[...]

Looking around, it seems to be an incompatibility between mac os x and *nix. I found a patch for a similar problem in navit, which loads the right library and function aliases.

Here’s my diff:

--- lighttpd-1.4.18/src/moov.c  2009-06-27 03:58:50.000000000 -0400
+++ src/moov.c  2009-12-07 16:49:50.000000000 -0500
@@ -73,11 +73,12 @@
 #define DIR_SEPARATOR '\\'
 #endif

-#ifndef WIN32
-#include 
+#include

+#define bswap_16 OSSwapInt16
+#define bswap_32 OSSwapInt32
+#define bswap_64 OSSwapInt64
 #include 
 #define DIR_SEPARATOR '/'
-#endif

 uint64_t atoi64(const char* val)
 {

After that, you can just continue merrily on..

make
make install

The directions for testing the plugin are a little buried on the maintainer’s site, but once I found them, everything seemed in order.

Unlike

Metadata standards (continued): technical metadata

Sat, 28 Nov 2009 16:36:16 +0000

In my last post, I compared the structure of a number of metadata standards, but focused mostly on descriptive elements. Here, I want to look at the technical metadata, describing the format, carrier and encoding. As before, I’ll highlight some interesting differences, but mostly let the structure stand alone.

Dublin Core

DC has a single element to capture the “file format, physical medium, or dimensions of the resource.” Given the breadth and scope of DC usage, this is about all one can hope for. Given an external grammar and vocabulary, this is probably sufficient for individual applications.

MODS

MODS provides another level of description for archival uses by splitting the physical description into 5 elements (+ a text note). In my mind, the reformattingQuality element may be the most important refinement. These elements (and their value dictionary and formats) map nicely into MARC, but might be insufficient for moving image materials.

  
      ppd0yxTPcxze2Imu.wdOa5SzK5wb
      DEFJ
      access
      k7xanTkreAc4nC
      
      mime/type
      digitized other analog

PBCore

Taking this further, PBCore splits its technical metadata into 20 fields with some suggested controlled vocabularies. PBCore 1.2 further refined this by adding essence tracks to describe each track. In addition to the technical, PBCore also captures some information important to access like publish dates (dateIssued, pbcoreDateAvailable), locations (pbcoreLocation), type of content (formatGenerations). PBCore allows for a flexible amount of metadata, track variations, and carrier types, but questionably maps to non-video materials.


    
        formatIdentifier0
        formatIdentifierSource0
    
    
        formatIdentifier1
        formatIdentifierSource1
    
    
        formatIdentifier2
        formatIdentifierSource2
    
    dateCreated0
    dateIssued0
    formatPhysical0
    formatDigital0
    formatLocation0
    formatMediaType0
    formatGenerations0
    formatFileSize0
    formatTimeStart0
    formatDuration0
    formatDataRate0
    formatColors0
    formatTracks0
    formatChannelConfiguration0
    aaa
    alternativeModes0
    
        essenceTrackType0
        essenceTrackIdentifier0
        essenceTrackIdentifierSource0
        essenceTrackStandard0
        essenceTrackEncoding0
        essenceTrackDataRate0
        essenceTrackTimeStart0
        essenceTrackDuration0
        essenceTrackBitDepth0
        essenceTrackSamplingRate0
        essenceTrackFrameSize0
        essenceTrackAspectRatio0
        essenceTrackFrameRate0
        aaa
        essenceTrackAnnotation0
    
    
        dateAvailableStart0
        dateAvailableEnd0
    
    
        annotation0

EBUCore

The approach EBUCore takes to this metadata is very similar to PBCore, although likely more rigorous and in-line with other practices. As with the other EBUCore elements, the original Dublin Core format element is offered, in addition to a range of additional elements. With typeLabel, typeDefinition, and typeLink, EBUCorea adheres better to controlled vocabularies and linked data practices.


    hnaz2hrZZAzhaTHio0WLKSJFF0MQ
    5707
    1804
    
    
    
    
        
    
    
    
    
    cdHADoR-vhZ
    vm
    
    4496
    nMknpC7ZGtqY4X1h

VIDEOMD

VIDEOMD, a METS extension for AV materials, is rooted more in the archival community than the preceding formats. It offers a number of interesting features, like the file checksum and compression fields, physical material description, and notes about calibration standards. While these elements are nice, and nicely supplement the high-level technical metadata in the other standards, this level of description is intensive and likely difficult for catalogers to adequately provide without additional infrastructure, in terms of tools, well-defined vocabularies, and training. Future iterations of PBCore could benefit from providing elements to capture some of the unique metadata without necessarily requiring such rigor. David Rice’s in-depth comparison of the two standards is an interesting read and offers some hope of collaboration and standardization between the communities.


  
    0
    0
    
      2001-12-31T12:00:00
      checksum_type
      checksum_value
    
    
      codec_creator_app
      codec_creator_app_version
      codec_name
      lossless
    
    0
    Fixed
    format_name
    format_note
    format_version
    sampling
    security
    Yes
    Master
  
  
    color_burst
    condition
    disposition
    
      dtv_aspect_ratio
      dtv_note
      dtv_resolution
      dtv_scan
    
    generation
    
      base_material
      binder
      disc_surface
      oxide
      reflective_layer
      stock_brand
    
    number_carriers
    phys_format
    signal_format
    
      timecode_record_method
      timecode_type
    
    
      tracking_type
      tracking_value
    
    CLV
    videotape_type
  
  
    aspect_ratio
    closed_captioning_note
    closed_captioning_type
    
    duration
    
      0
      0
      0
    
    note
  
  
    image_data
    target_id
    target_type

Unlike

A comparison of metadata standards for media

Thu, 12 Nov 2009 02:28:32 +0000

In this post, I will introduce five different XML schemas for media metadata with brief introductions for each. These five, while certainly not comprehensive, are sometimes used to provide metadata for access. In place of actual catalog records, randomly generated instances will be used to focus on the form of the schema, rather than the content (which gets into discussions of data dictionaries, which, while important, are certainly better left to subject-matter experts). Future posts may perform comparative studies of metadata classes (entities, technical, events, etc), but in this post the comparison is left as an exercise for the reader.

Note: Some of the examples have been truncated or reformatted in an effort to cut down on redundant information, but may render the examples invalid.

Dublin Core
As a starting point, there’s the basic Dublin Core, which is a great standard and can be used to generally describe just about anything. It is a widely supported standard and very easy to get started with. Qualified Dublin Core brings in an enhanced vocabulary that makes it a very attractive solution for heterogenous collections. The downside, however, is that the simplicity comes at the cost of specificity and hierarchy found in media collections.

The basic Dublin Core terms and probably sufficient to describe everything, but the additional dcterms offer an additional layer of specificity useful in thinking about serious reuse.

PBCore
PBCore builds some of the fundamentals of Dublin Core and offers, as its key innovations, increased precision about types and authorities (although not complete) and technical instantiation metadata. Similar to Dublin Core, the PBCore elements beginning with pbcore* (the “containers”) are repeatable, allowing a lot of flexibility in capturing metadata.



    
        identifier0
        identifierSource0
    
    
        title0
        titleType0
    
    
        subject0
        subjectAuthorityUsed0
    
    
        description0
        descriptionType0
    
    
    
        genre0
        genreAuthorityUsed0
    
    
        relationType0
        relationIdentifier0
    
    
        coverage0
        Spatial
    
    
        audienceLevel0
    
    
        audienceRating0
    
    
        creator0
        creatorRole0
    
    
        contributor0
        contributorRole0
    
    
        publisher0
        publisherRole0
    
    
        rightsSummary0
    
    
        
            formatIdentifier0
            formatIdentifierSource0
        
        dateCreated0
        dateIssued0
        formatPhysical0
        formatDigital0
        formatLocation0
        formatMediaType0
        formatGenerations0
        formatFileSize0
        formatTimeStart0
        formatDuration0
        formatDataRate0
        formatColors0
        formatTracks0
        formatChannelConfiguration0
        aaa
        alternativeModes0
        
            essenceTrackType0
            essenceTrackIdentifier0
            essenceTrackIdentifierSource0
            essenceTrackStandard0
            essenceTrackEncoding0
            essenceTrackDataRate0
            essenceTrackTimeStart0
            essenceTrackDuration0
            essenceTrackBitDepth0
            essenceTrackSamplingRate0
            essenceTrackFrameSize0
            essenceTrackAspectRatio0
            essenceTrackFrameRate0
            aaa
            essenceTrackAnnotation0
        
        
            dateAvailableStart0
            dateAvailableEnd0
        
        
            annotation0
        
    
    
        extension0
        extensionAuthorityUsed0

EBUCore
EBUCore was a concurrent (and continuing) effort from the European Broadcasting Union that does a better job building and extending the Dublin Core semantics, providing better authority control and type definitions, and significantly better support for personal and corporate information. There is also clearly some thought towards linked data, although neither formalized or complete. One great thing to notice is the embedded Dublin Core available in many of the EBUCore containers.



    
            
                <dc:title xml:lang="en-UK">eVIHDSz</dc:title>
            
            
                u
            
        
            
                
                        JMkP
                
                AWU5
                Cs3t
                gVqhVj4JYm1jNpE
                
                    
                                N0OHIku0yhRAfQNz
                                F_S88txz7wYC-5MtA8L-GN582s
                    
                    EpUHl
                    LpvL6If0bs
                    c_ln
                
            
            
                sQYVwjfz
                S-Hs
                bYo_gb8MZsoMSxz3bv-McC_d
                
                    
                            wyhVZ.Qr_vrq2LG
                    
                    nwnR3APftPn
                    ypJgH5.khIJJKnEYjQMMQ
                    p

                
            
            
        
        
            Yd85RPmgSpg
            http://prHfhlYz/
            JLvII3b.B_JoRrZbO5NnckvClA
        
        
            Bk.WPZZqAdcmAJiubnnQVA
        
        
           [...]
        
        
            
                
                        hSaqGAVtm
                
                M
                NXxA_kZf.ChokbLOBk7n
                m
                
                    
                                AD-I
                                a4bZfNUj1GYtqMeTkMlNvbUkyXl1
                    
                    YiRe6tNuMUkpdzbSHcMftzjoGh-RYG
                    P6ixWHzug
                    NAQAJfew3D3IDkU.jfLvcq34ku
                
            
            
        
        
            ehyw5D-J
            2010-05-06
            2010-07-02T14:25:33
            2010-11-30
            2010-10-23
            2010-03-02T14:25:33
        
        
            iyn.qujSLIqK9Ndq_9nOb-e2v4t
            http://iAkynyWf/
            Hbk2
        
        
            hnaz2hrZZAzhaTHio0WLKSJFF0MQ
            5707
            1804
            
            
            
            
                
            
            
            
            
            cdHADoR-vhZ
            vm
            
            4496
            nMknpC7ZGtqY4X1h
        
        
            jwJAPPiux
        
        i7KtJiGGQhBlN8sGtmr.abnEwpDmzO
        
            LcH4OygXVb5BaSnhLp
            http://ZUVQarBI/
        
        
            http://SqpJEXle/
        
        
            y8_-k7QO0DJV_VCs-ojeXEH75
        
        
        
            
                X7GuUj5QjZPX
            
        
        
        
        
        
        
        
        
        
        
        
            xmcaSqXp0J
            
                
            
            
                
                    VX
                        0.12997484
                        0.6069337
                    http://fDMzDAlW/
                
            
        
        
            C2B2mASSqkQe7-36htV0GMrGI1HqXJ
            http://VSluGnul/
            
                
                
                
            
            ft2IqhaHKMptvbMIavn
            
        
        LPuFQHemE6gxK
        
            2009-12-16T14:25:33
            CZ5N.0L5H
                2011-01-04T14:25:33
                qJCTyAUYVuAq5gW
                2011-03-12T14:25:33
                UD8lhfDD
                2010-07-18T14:25:33
                bfvJQlo
        
        
            [...]
            [...]

NewsML
While both PBCore and EBUCore make some attempts to be type-agnostic, other schemas have grown up in content-specific areas. One example of this is NewsML, which was developed to help exchange (and schedule) news stories. It packs a lot of information in, with some really robust provenance handling (with creator + modified attributes for every element). For brevity, I’ve removed a lot of that detail. Like EBUCore, there are some hints of linked data with attributes for URLs and HTML-style anchor links built into the schema. Like PBCore and EBUCore, it also offers some basic technical metadata.



  
    
      <a id="ID005" >
        <span id="ID007" ></span>
        <ruby id="ID009" >
          <rb>u</rb>
          <rt>Rb-uM8Q7AXVoZA_KyQqMDJSbFt8p</rt>
        </ruby>
      </a>
      <a id="ID011" ></a>
    
    
    
    
  
  
    
      DwMkoyFyklSGm1
      
        2010-07-25
        2011-04-24
        
          R
          
            1998-04
            2010-05-08
          
        
        
          igob.0sDFe-J
          Cs7bj2.jLmgnhy2fCP6Dn
          UsKtcxGDEDKplu
        
      
    
    
      
    
    
      
        
          Tl
          lN7lM
          fVE43gr6caHO-kvH9.LZYX8
          w
        
      
    
    
      
    
  
  
    
      GuSM2
    
    
      
        2011-06-02T15:27:33
        2010-12-09T15:27:33
        
          
            hn1eohZbVU3bLVhMHxBGsYhNaSaF
            
              l0jkXD5d3n.9L1scL3NV
              CURNNGp7
            
            BZDUDu3qT8hD
          
          v2okn4BTwSL-7dNaVIrRdUD
        
        
          B
          _D0.odJ39HAegCnhE1BI580O_wI
        
      
    
    2010-01-30T15:27:33
    2010-02-02T15:27:33
    2010-09-21T15:27:33
    
      _Cm9xt7NT9fxu_MEhhuX36
    
    
      T
    
    Zn0
    YyW_5Xf5Lj7n2byCMYOxBc3fCSZDy
    J-R0ftmAFuFVqoAKVI
    
      QJSXR8_v8a93_5X
    
    
      <ruby id="I3677" >
        <rb>GYAOPe</rb>
        <rt>sG95xTbyoeAVKUPeh0ZubG5ckPBom2</rt>
      </ruby>
    
    
    
      Q0j2YVNmXE2rlJ5-b1
    
    http://wXTRhWvM/
    
  
  
    
    5
    2003-09
    2011-02-01
    
      N-oCsUqBwmcuQjzTWAKG7
    
    bwfnPNcFxz-QTAe9WLHNklkYG0.a
    
    
    
      
        
      
      
        
        
        
      
    
  
  
    
    
    
    2
    1991
    2011-11-07T15:27:33
    
      
      
        2010-01-26T15:27:33
        1995
        
          PJNOS
          mPMgrmIR_kb1Y9Bt.ZBsyS
          Tp.yZHIkgY
        
        
          
            
          
        
      
    
    
      ktAcBvSCVpCp.eAc
      
    
    WP_ZmNC6p9ZPwZXJJqbLw
    
      w

MPEG-7
Finally, MPEG-7. While the other standards have mostly focused on the high-level descriptive aspects, MPEG-7 takes a different approach and allows for a lot of highly technical metadata recorded at the frame-level. It is designed to be packaged with the media assets in order to have referents for its description. In this excerpt, I’ve focused primarily on the high-level metadata, which diminishes a great deal of its utility. Further investigation of MPEG-7 may be worthwhile, but would likely require external tools to manipulate it. One amusing this to note is the available in .



        
        
            0.3030908
            mUM
             
            
                L0..vYV7
            
            Q0VDyH
            H9Vv5JOVE2t4o
            
                    
                        rHQ_UlvgzO
                        RTAiAQSl-5gqtJSG
                        
                            N8tLl7hhA2yb-
                            mst
                        
                    
                        
                                
                                
                                        http://KNyXKlot/
                                    6015
                                
                        
                    
                            u-6aFcAzEAhVc
                    
                    
                        
                            Soaky8
                            OhLZxfcgs
                            
                                BjT
                                ypobl-My.GMxfk4TN00v9opidO
                            
                        
                        
                    
            
            
                    
                    NVM5sWSn
                    
                        AeW8IL
                        BNV9.ciOPaWiWSKNIJCPrh8SYN
                        
                            k_71PU6BGH0KhysiBbbSggPF
                            _ojS_n
                        
                    
                    aeykENRWE5jqLTo9TKk4G5
                    
                        HagwatvYqGC0FcFUrkE-U3fqfrs59Y
                        UBF676Nd
                        
                            r8.3T2hnqrr8r9.S5N3Rj81YE0
                            yv9h3CfRpp6LCozldNNDRkN9RkUC-s
                        
                    
                    
                        
                    
                    
                        vXeoyI
                        iRFHyD
                        
                            uBQaQX36FJv
                            ND2
                        
                    
                    jW-PIZ
                    R-LC
                        
                            g3y
                            rYMpktTLNoWPv_-69S
                        
                        JK91k
                    
                        DOcVXw_liUkVRLUXPI8GhkY8S6
                        _
                        Di2HkVg3E7
                        http://alweWoFq/
                    
            
            2894F4430+74:93 
            
                
                    yj5btGGUiG8H
                    H58z
                    
                        QvQYcIj3.vSUDmdj9G0-CFquuG
                        vZBlUB6i86vZoBDHrL3MCnd0
                    
                
                
            
            
                I0kMKLBHtwvqwVy

Unlike

Teaching PBCore, Questions and Notes

Wed, 04 Nov 2009 19:13:22 +0000

The questions below are loosly based on those raised by particpants in the introduction to XML workshop presented at the Association of Moving Image Archivists 2009 conference in St. Louis, MO on 3 November.

In general, tangible examples are crucial to the teaching and understanding of PBCore. At present, the PBCore examples are hap-hazard and follow little logical progression. An improvement in this area would be beneficial to the adoption of PBCore. In addition, tools should be created to support new PBCore-based applications which would make distiguishing between well-formed XML, valid PBCore, and PBCore that conforms to a community of practice easier.

- Where are the XML attributes?
After an introduction to XML, which taught the partipants about the basic building blocks of XML (elements, entities, and attributes), the lack of attributes in PBCore was confusing. Rather than:

Jimmy Carter

PBCore requires:


Jimmy Carter
Program

As a developer, the additional mechanics to parse each type, each authority, or each role are annoying copy+paste jobs, but it is clear that even those new to XML develop the same expectations. With some of the recent developments from DCMI to make Dublin Core more relevant to the changing metadata landscape, it seems like PBCore has failed to evolve.

The reason, as best I can determine, is the PBCore 1.x schema was developed based on existing XML exports from a relational database where that convention is born out of the need for a semantically agnostic schema rather than proper schema creation.

- What is PBCore’s relation to Dublin Core?
PBCore is introduced as being a derivative or extension of Dublin Core, but for some shared element names, there is no obvious relationship. This should either be clarified in future development or dropped.

- What is the difference between the formatPhysical, formatMediaType, and formatGenerations?
These three instantiation-level metadata elements all describe similar problems slightly differently

* formatPhysical (or formatDigital, perhaps) describes the carrier format, which may be independent of the content on the carrier
* formatMediaType describes the content present on the carrier
* formatGenerations describes the type of content on the carrier

The PBCore value lists could be clarified to remove some of the current (seemingly) redundant information

- Why are formatPhysical and formatDigital formatted different? Or, why wouldn’t one use multiple instantiations to express the different formats for which an item is available?

The value list for formatDigital is based on the IANA MIME type registry, while the formatPhysical list is the aggregate of the source elements, which is reflected in the inconsistency of formatting. Could the formatPhysical list become more cohesive and resemble MIME types?

The relation between current instantiations is, at best, unclear and not systematic. The biggest flaw in the current approach is that it is difficult to express the provenance of an instantiation and it’s relation to the intellectual work. The current situation also breaks the 1:1 correspondance between an instantiation and a carrier/file/etc. Some major restructuring, possibly breaking backwards-compatibility is necessary to correct these issues. In the meantime, I would recommend creating a new instantiation for each instance and using the pbcoreAnnotation field to supply basic provenance information.

- The PBCore outline graph is confusing.
As is, the outline graph mixes XML elements with conceptual groupings which makes it confusing to someone new to XML or to PBCore. The graphic could be easily revised to use shaded groups to communicate the content classes, rather than tree nodes.

- The PBCore metadata dictionary picklists provide no definitions or best practices
The metadata dictionary, which may be the most important part of PBCore 1.x, is marginalized on the website. The picklists are offered only as lists and fail to provide appropriate definitions for titleType, descriptionType, etc. Without this guidance, each implementor is forced to make determinations without respect to a community of practice. Taking descriptionType as an example, guidance is needed to describe when to use the format-specific types (program, series, etc) vs the generic type labels (abstract, summary).

- The PBCore website conflates schema rules with best practices
The PBCore website recommends best practices and guidelines for usage closely integrated with the schema requirements. This placement is confusing; while the best practices are very important and are essential resources for understanding, it adds difficulty to the understanding of PBCore.

- A schema-validating XML editor complains when the XML document lacks recommended or optional fields
In particular, oXygen indicates to the user that fields like pbcoreGenre are REQUIRED for conformance to PBCore, while the website leads one to believe this is not the case. In fact, this should not be the case because genre is very specific to broadcasting/traffic needs and will likely be missing in general usage.

This leads me to believe that PBCore should examine the approach the TEI community took with regard to modulization. Proper modulization would provide implementors with a relevant set of metadata elements necessary for use, and perhaps make it easier to integrate PBCore with other metadata schemas (for example, a rights schema or technical metadata standard), leaving PBCore responsible for description and rules for aggregation.

- How do you exchange records? Or, how can I put multiple description documents in the same file?

A PBCoreDescriptionDocument, according to the PBCore schema, should have only one document per file, which is common XML practice, but unknown to those new to XML. Participants were attracted to aggregations as a way to deliver contextually complete documents containing metadata records for relations, etc. Other standards have explored aggregations independent of standards (say, Atom or OAI-PMH), which is probably a more-sound approach.

- Extensions are hard, confusing.
Yep.

Unlike

15 ways to improve PBCore

Tue, 27 Oct 2009 18:43:16 +0000

This is a post describing shortcomings and potential improvements for PBCore, an XML markup for media material interchange. These suggestions try to work within the current confines of PBCore, rather than introducing radical changes (which could bring PBCore more in line with the rest of the XML and linked data worlds). Further, we recognize the strength of PBCore is in descriptive metadata, and these suggestions are primarily to strengthen those components, rather than trying to compete on technical metadata.

Define what all the data dictionary elements mean — “clip”, “element”, “actuality”, “version of”, etc. These need to be defined in order for the community to better apply consistently. Other communities have come up with these already – we just need to determine which ones apply to which elements. See for example, the European Broadcasting Union does a nice job of distributing machine-readable XML definitions for their data dictionary.
Enhance semantics of relation types by creating an ontology (using rdfs or similar, like the Fedora RELS-EXT ontology) – eg. instead of simply “version of” allow “derivation of”, “copy of” “identical to” etc.
PBCore only has contextual date on individual instantiations, but we want an overall date with types for created/issued/etc (e.g. the date an interview was conducted). A similar issue exists for locations. Both of these are different from pbcoreCoverage — coverage is about the content, rather than the context.
Format of the content — whether it is an interview, a panel discussion, a live event, b-roll, beauty shots, etc. formatGenerations provides a piece of this puzzle, but this is ultimately descriptive metadata, which probably don’t belong in an instantiation. EBUCore provides for part of this with a controlled vocabulary for editorial formats, but it’s not granular enough (e.g. Discussion/Interview/Debate/Talkshow). Our suggestion is to explore enhancing the genre data dictionary to include archival descriptors like “interview” “b-roll”, which would solve this in a backwards-compatible way.
Machine parseable rights language; we’re embedding the Open Digital Rights Language (ODRL) as a member of pbcoreRightsSummary, but it would be nice to have a common way to express rights (both rights the publisher has, and rights granted by the publisher to the user). An alternate (and perhaps desirable and necessary) solution would be to at least investigate better ways to combine PBCore with established schemas like ODRL, MODS, etc.
A way to identify the primary title and description of an asset, for use in a discovery interface. Existing solutions, like picking titles based on hierarchy, or using a separate metadata document, are flawed.
A formal way to order, prioritize, and relate instantiations within a record (e.g. programs within a series, provenance/hierarchy of digital instances).
A way to label the type for a pbcoreSubject is (e.g. person, organization, place, date, etc), in addition to the existing authority reference.
Authority references should be available in most (if not all) PBCore containers, which could help enable linked data applications. This could be accomplished through new xml attributes, which would be ignored by legacy applications, and perhaps better in line with other standards.
Better handling of “element” level materials, for archival raw footage and similar. Finished programs are handled decently in the existing PBCore, but the data dictionaries aren’t prepared for this level.
Adopt proper RDF relationships for PBCore relations.
Consider adding educational levels and standards. PBCore currently addresses this tangentially with audienceLevel and audienceRating.
Better way to handle metadata about people, whether by enhancing the existing structure, supporting an hCard microformat, or otherwise.
Semantics to deal with thumbnails for discovery interfaces, or how to attach visual representations/facsimiles of a PBCore media instantiation. This is probably a low priority, nice to have change.
Content flags, which include advisory messages about sensitive content, are regularly created for broadcast programs, but PBCore doesn’t provide a way to capture these. Perhaps the best way here is to add time-based metadata to the descriptive material (but, then, what do you base the timecode against? See next.)
BONUS: Add timecode information to instantiations and relationships to identify sections of content, in order to support time-based metadata, content flags, etc.

Unlike

Fall, 2009

Sun, 11 Oct 2009 23:07:21 +0000

Autumn Hills Orchard, Oct 10, 2009

Unlike