This chapter describes an approach to the development of a metadata application profile. It is particularly concerned with the class of application profile which is optimised for a specific use-case, rather than those which are more concerned with supporting general interoperability in a broader domain. The example of the development of a particular application profile, RIOXX, is used to illustrate some of the methodology discussed. Much of the approach described in the chapter was designed during the course of the development of RIOXX. Issues which are given particular consideration include a focus on the close involvement of ‘implementors' (normally software developers), the adoption of ideas from agile software development, continuous testing and open development, and ongoing maintenance and sustainability “on a shoestring”.
TopIntroduction
Application profiles consist of data elements drawn from one or more namespace schemas combined together by implementers and optimised for a particular local application. (Heery & Patel, 2000)
This is one of the earliest and, arguably, the best definition of the term application profile. The author prefers this definition because, while mentioning ‘data elements’, ‘namespaces’ and ‘schemas’ (all crucial aspects), it is also careful to emphasise the importance of the involvement of ‘implementers’ and ‘optimisation’ for a ‘particular local application’.
While this definition suggests that application profiles ought to be focused on meeting particular requirements, the recent history of their varied development places them on a scale, from those which have been developed to enable broad interoperability in a general domain or ‘application space’, to those which are, indeed, optimised to enable a particular application. The concept of interoperability is intrinsically bound up in the development of metadata standards and profiles. However, interoperability and optimisation do not always complement each other as features, and application profiles tend to emphasise one or the other. For example, the Scholarly Works Application Profile (SWAP) is described as “a DC Application Profile for describing an eprint, or scholarly work” (“Scholarly Works Application Profile”, 2009). The documentation for this application profile says nothing about use-cases and it does not identify any ‘particular local application’. SWAP, like plenty of other application profiles, is designed to facilitate as-yet-unknown applications by explaining how to describe a particular type of resource to an appropriate level of detail. Essentially, this kind of support for interoperability is about enabling the possibility of future interoperation, rather than being focused on any particular, intended implementation. As such, if SWAP were to be placed on the aforementioned scale, it would be positioned close to the 'interoperability' end of the axis, and some distance away from 'optimisation'.
This chapter is concerned with the other end of that scale, with application profiles which are optimised for particular local applications. The specific example of RIOXX is used to illustrate a methodology for the development of an application profile which focuses on supporting its intended implementation. RIOXX has been developed to address a specific use-case: this use-case together with the application profile itself are briefly introduced, while the bulk of this chapter is concerned with the methodology used in development, deployment and implementation.