What will be the format of the event?

In advance of the hackathon, participants are asked to fill out this form so that we can get a sense of the experience and skills of those who plan to attend. On the first day of the event, we will begin with welcome and introductions, review the agenda, and then break into groups to work on a variety of tasks. Groups may be identified as those working on intellectual content, intellectual property, technical, etc.
The days themselves will be structured something like this. Coffee/tea will be provided. Lunch is on your own.

Summary & Background

The PBCore RDF Ontology Hackathon is occurring out of a growing need for PBCore users to express their metadata in RDF. A number of PBCore users contribute to and are part of the Project Hydra community, a collaborative, open source effort to build digital repository software solutions at archives institutions. Hydra is built on a framework that uses Fedora Commons as the repository for storing metadata. Many users are seeking to update their Fedora repositories to the latest version (Fedora 4), which provides a great opportunity to develop an RDF data structure. If PBCore had an RDF ontology, it would be easier for PBCore users to take full advantage of Fedora 4 capabilities in managing data and encourage adoption of Fedora 4.

We envision building upon existing knowledge bases that are already well established. In particular, we hope to harmonize the EBUCore ontology with PBCore and determine what existing terms from the EBUCore vocabulary can be re-used, and what concepts may be unique to PBCore that would deem the need for additional terms.

PBCore is a metadata schema for audiovisual materials. Its original development in 2004 was funded by the Corporation for Public Broadcasting, with a goal of creating a metadata standard for public broadcasters to share information about their video and audio assets within and among public media stations. Since its conception, PBCore has been adopted by a growing number of audiovisual archives and organizations that needed a way to describe their archival audiovisual collections. The schema has been reviewed multiple times and is currently in further development via the American Archive of Public Broadcasting and the Association of Moving Image Archivists (AMIA) PBCore Advisory Subcommittee.

The Schema Team is working on an updated version of PBCore (PBCore 2.1), the changes of which will consist of minor tweaks and bug fixes, and is expected to be released in March 2015. Other Teams on the Subcommittee are working on PBCore outreach, education, documentation, and a new website.

Working Groups

Participants should sign up for a working group. On the days of the event, these sections will be filled with suggestions and links to documentation created by the working groups.

Intellectual Content Working Group

This group will focus on the intellectual content part of the knowledge base. Intellectual content in PBCore XML is currently expressed through elements like pbcoreTitle, pbcoreAssetType, pbcoreAssetDate, pbcoreSubject, pbcoreDescription, pbcoreGenre, pbcoreRelation, pbcoreCoverage, pbcoreAudienceLevel, pbbcoreAudienceRating, pbcoreAnnotation, etc.

Participants

Intellectual Property Working Group

This group will focus on the intellectual property part of the knowledge base. Intellectual property in PBCore XML is currently expressed through elements like pbcoreCreator, pbcoreContributor, pbcorePublisher, pbcoreRightsSummary, and roles.

Tips and Advice from the Community

from Karen Coyle

Don't lean too heavily on Protege. Protege is very OWL-oriented and can lead one far astray. It's easy to click on check boxes without knowing what they really mean. Do as much development as you can without using Protege, and do your development in RDFS not OWL. Later you can use Protege to check your work, or to complete the code.

Develop in ntriples or turtle but NOT rdf/xml. RDF differs from XML in some fundamental ways that are not obvious, and developing in rdf/xml masks these differences and often leads to the development of not very good ontologies.

from Jean-Pierre Evain

I have personally no issue whatsoever with Protégé or RDF/XML for the type of ontology we seem to be aiming at

I agree that OWL is probably not required. But this doesn't prevent using Protégé. Of course one needs to know what is specific to OWL.

Need more info?

If you have questions or need more information, feel free to contact Casey Davis at casey_davis [at] wgbh [dot] org.