Maybe you’ve heard of application profiles. Maybe not. What is an application profile? What can applications profiles be used for? How do application profiles relate to FRBR, Dublin Core, or RDF? These slides prepared by John Phipps, Karen Coyle, and Diane Hillmann are a great starting point to answer these questions and more.
Tag Archives: application profiles
I recently ran across this article, “Assessing FRBR in Dublin Core Application Profiles” by Talat Chaudhri (go to: http://www.ariadne.ac.uk/issue58/chaudhri/).
Talat talks about how Dublin Core Application Profiles came to based on a FRBR model. Talat introduces the problem of DCAPs and SWAPs as follows:
Efforts to create standard metadata records for resources in digital repositories have hitherto relied for the most part on the simple standard schema published by the Dublin Core Metadata Initiative (DCMI) , the Dublin Core Metadata Element Set, more commonly known as ‘simple Dublin Core’ . While this schema, by and large, met the aim of making metadata interoperable between repositories for purposes such as OAI-PMH , the explicit means by which it achieved this, a drastic simplification of the metadata associated with digital objects to only 15 elements, had the side effect of making it difficult or impossible to describe specific types of resources in detail . A further problem with this ‘flat’ metadata model is that it does not allow relationships between different versions or copies of a document to be described.
The extension of these 15 elements in DCMI Terms, known as ‘qualified Dublin Core’  was an effective admission that richer metadata was required to describe many types of resources. Arguably it remains feasible to use ‘simple Dublin Core’ fields for certain resource types such as scholarly works in cases where especially complex metadata are not required. The problem has been that almost every repository uses these elements to some extent according to local needs and practice rather than adopting a standard. Inevitably this has had a negative impact on interoperability.
Consequently, the concept of application profiles (APs) was developed. In essence, these are “…[metadata] schemas which consist of data elements drawn from one or more namespaces… and [are] optimised for a particular local application.” As they were originally formulated, they were intended to codify the practice whereby it was acknowledged that “…implementors use standard metadata schemas in a pragmatic way.” Consequently, on the principle of the “…maxim ‘there are no metadata police’, implementors will bend and fit metadata schemas for their own purposes.”  On the other hand, the engagement of both standards makers and implementors led first to the development of the Scholarly Works Application Profile (SWAP) and subsequently a range of other JISC-funded Dublin Core Application Profiles (DCAPs) .
Though I am not as familiar with APs as I would like, I found that this article raised an important question in the conclusion. Here, Talat asked whether DCAPs and SWAPS, which have inherited a FRBR model, are practical. This question echoes the concern of many librarians and information professionals who believe that steamrolling RDA, which is based on FRBR, foreword without any testing or seeing how it performs in everyday situations, is blind-sighted at best.
This concern becomes especially acute when FRBR aims to:
“to produce a framework that would provide a clear, precisely stated, and commonly shared understanding of what it is that the bibliographic record aims to provide information about, and what it is that we expect the record to achieve in terms of answering user needs.” (p. 2, http://www.ifla.org/VII/s13/frbr/frbr.pdf).
The issue this raises relates to the practicality of a theoretical framework. In other words, how practical are theoretical solutions to complex problems? This question opens the arena towards a large debate, already in progress. Some believe that as a theoretical framework, FRBR guides the way without having to explicitly explain every detail, hence the word framework; this allows an opportunity to iron out details of how FRBR concepts perform in the real world. Others think that because FRBR has not been tested, it lacks the elements necessary to respond to problems that might arise while using this framework. These are but 2 examples of a myriad of thoughts on FRBR and its functionality. In regards to these two, I think both points of view contain elements of truth. Theoretical frameworks, since they are based on ideas, are open to interpretation and, thus, a horizon of possibilities, in the manner of Paul Ricoeur’s phenomenological epistemology. I think it is on us to choose the horizon of interpretations wisely such that the practical implementations are practical in reality and help to advance the 4 tasks of FRBR: find, identify, select, and obtain. That is why the discussion on FRBR and RDA are so important.