Teaching PBCore, Questions and Notes

<title type="Program">Jimmy Carter</title>

<pbcoreTitle>
<title>Jimmy Carter</title>
<titleType>Program</titleType>
</pbcoreTitle>

15 ways to improve PBCore

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6.  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.
7. A formal way to order, prioritize, and relate instantiations within a record (e.g. programs within a series, provenance/hierarchy of digital instances).
8.  A way to label the type for a pbcoreSubject is (e.g. person, organization, place, date, etc), in addition to the existing authority reference.
9. 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.
10. 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.
11. Adopt proper RDF relationships for PBCore relations.
12. Consider adding educational levels and standards. PBCore currently addresses this tangentially with audienceLevel and audienceRating.
13. Better way to handle metadata about people, whether by enhancing the existing structure, supporting an hCard microformat, or otherwise.
14. 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.
15. 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.)
16. BONUS: Add timecode information to instantiations and relationships to identify sections of content, in order to support time-based metadata, content flags, etc.

Fedora + Ruote workflow system

Fedora, Blacklight, and Ruby on Rails

• The unique identifier field `id` is hard-coded into Blacklight, while my existing data used the field name `PID`; see CODEBASE-171
• The unique identifiers in my repository began with a qualified namespace in the form "org.example.repository", which broke the Ruby on Rails default routing system

  map.resources(:catalog,
    :only => [:index, :show, :update],
  […]
    :requirements => { :id => /([A-Za-z0-9]|-|\.)+:(([A-Za-z0-9])|-|~|_|(%[0-9A-F]{2}))+/ }
  )

BagIt workflows