Reflecting on the Application Profile (APAP) Element Set Version 0.1
Looking Back and Moving Forward
Operational definitions of terms used in this post:
- Metadata: “data about data,” or information that conveys descriptive, administrative, or structural meanings about a particular resource or group of resources.
- Metadata element: metadata about a particular property/facet of an information resource.
- Metadata schema: a formalized specification of metadata elements made by a singular organization.
- Metadata application profile: a collection of metadata elements to describe a specific type of information resource. Associated elements can either be locally-created or derived from existing schemas.
The Account/Post Application Profile
In my second year of library school at Syracuse University, I took IST 681: Metadata. Although I had collaborated on the MetaFAIR application profile as part of my research in Syracuse’s Metadata Lab, that course afforded me my first opportunity to establish a metadata application profile on my own. At the time, I had been intrigued by how librarians interacted, collaborated, and networked on Twitter (especially within the informal community commonly referred to in the profession as “Library Twitter”). Additionally, around that time, I had become an avid reader of blogs like Alan Samry’s Stump the Librarian. Due to this overall interest in web communication, I developed Version 0.1 of the Account/Post Application Profile (APAP) Element Set.
At its core, APAP is an element set intended to describe blogs/blog posts and social media accounts/posts. Its elements are derived from the Friend of a Friend (FOAF) vocabulary and the Dublin Core Metadata Terms. Despite the influence of FOAF during the drafting phase, APAP v0.1 is comprised of local elements and elements from the DC Terms. The elements are organized into two groups: elements to describe blogs/social media accounts and elements to describe blog posts. They are divided between the wrapper elements “Account Wrapper” (required, nonrepeatable) and “Post Wrapper” (nonrequired, repeatable). This modularized structure was inspired by Getty’s CDWA Lite schema.
APAP v0.1 in Practice
An example XML metadata record using APAP v0.1 can be found below. The U.S. Fish and Wildlife Service Library’s Medium account and one of its posts are described. Note the prefixes: dct refers to the Dublin Core Terms, and tway is the prefix for locally-created elements. One of the areas on which I focused the most during APAP’s development was the dct:references element. This was intended to give metadata record creators the ability to show account-level and post-level linkages between the resource being described and other items on the web.
Areas for Improvement
A year has passed since I developed this iteration of APAP. My experiences since then, especially as a practicing metadata librarian, have given me clear ideas on how to improve APAP for Version 0.2.
Modularity
A problem with APAP v0.1 is that the dct:references element, while repeatable, does not provide any further context about related resources other than their URLs. As noted previously, I modeled APAP’s wrapper structure on CDWA Lite. In that schema, wrappers are meant to compartmentalize different aspects of description, such as a work of art’s physical location, date of creation, style, and related pieces. In the latter’s case, related works exist within self-contained wrappers that have more than just a web link to another resource, which is what I did in APAP v0.1. For instance, the relational wrapper in CDWA Lite features the metadata element Related Work Relationship Type, which can have values like “part of, larger context for, model of, model for, study of, study for rendering of, copy of, etc.”
My plan for APAP v0.2 is to introduce a “sub-wrapper” at the account/post levels to augment the existing dct:references element. This rework will likely derive some/all of the elements from CDWA Lite’s Related Work elements, necessitating the use of a new prefix (e.g., cdwal).
Element Order
In APAP v0.1, elements at the account/post levels are arranged in alphabetical order based on the suffixes (contributor, description, etc.). In practice, this creates metadata records that are harder for humans to parse. In APAP v0.2, I will likely use a format like the following:
<dct:title>FWS Behind the Lens: Tom Koerner</dct:title><tway:contributor>U.S> Fish and Wildlife Service Library</tway:contributor><tway:contributorParentOrganization>U.S. Fish and Wildlife Service</tway:contributorParentOrganization><tway:dateCreation>2020-06-24</tway:dateCreation><dct:identifier>https://medium.com/fwslibrary/fws-behind-the-lens-tom-koerner-cddb24174a81</dct:identifier><dct:references>https://www.fws.gov/refuge/rainwater_basin_wmd/</dct:references>
Conclusion
Constructing metadata application profiles requires persistence and iteration. As evidenced above, my first version of APAP was functional, but it had design flaws that would hinder practical implementation. This application profile is still a work in progress, but Version 0.2 should amend some of the more glaring problems.
