Search Disabled |
|
|
|
Search Options | Help | Site Map | Cultivate Web Site | ||||
|
|
|||||
| Home | Current Issue | Index of Back Issues |
| Issue 3 Home | Editorial | Features | Regular Columns | News & Events | Misc. | ||
By Makx Dekkers - January 2001
Makx Dekkers of PricewaterhouseCoopers describes some recent developments in the area of application profiles and how application profiles are being used, based on experiences in the SCHEMAS project.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you want to define a metadata schema for your electronic resources, you may want to base your work on what others have done. Until some time ago, everybody who needed to define a metadata element set (or schema) to be used for a particular project or collection of resources, invented their own solution. It is becoming apparent that this approach, re-inventing the wheel so to speak, is not the optimal way of working.
It is now becoming accepted that it is a good starting point to base the definition of a local schema on work that other people have done. To support this, the SCHEMAS project [1] aims to build an information service where schemas developed in many places around the world can be found. For a start, this information service will begin to solve one of the major problems encountered by metadata schema designers: the difficulty to find out what has happened elsewhere.
However, finding out about existing schemas is only a first step towards the ultimate goal: harmonising usage and converging on formal or de-facto standards. As has been identified by the SCHEMAS project from its inception, any particular project or product has specific requirements that cannot be fully met by standards "straight from the box". Almost all practical implementations will have to mix and match elements from various schemas and have a potential need to define additional elements of their own. This mechanism of mixing and matching and defining private elements results in what is now called an application profile.
The concept of application profiles has emerged in discussions on metadata schemas in the last year, in relation to work that is being done on metadata registries, specifically in the Dublin Core Metadata Initiative [2]. The partners in the SCHEMAS project, and specifically Thomas Baker of GMD and Rachel Heery and Manjula Patel of UKOLN, have made major contributions to this discussion.
Baker, in a “strawman proposal” to the Dublin Core Registry working group [3] defines application profiles as entities that declare which elements from which namespaces underlie the local schema used in a particular application or project. In his view, application profiles “re-use” semantics from namespaces and repackage them for a particular purpose. This is in line with Heery and Patel [4] who define application profiles as schemas consisting of elements drawn from one or more namespaces, combined together and optimised for a particular application. They suggest that a distinction can be made between a namespace schema (containing all those elements defined for a particular namespace) and an application profile schema (containing combinations of sub-sets of one or more namespace schemas).
It needs to be pointed out that the term namespace in these definitions should be read as the metadata element definitions and semantics defined within those namespaces. As an example, the namespace for the Dublin Core Metadata Element Set, version 1.1 [5] can be referred to (in XML) as:
xmlns:dc= "http://purl.org/dc/elements/1.1/"
At the location specified by the URL, the 15 Dublin Core elements and their semantics are defined.
The SCHEMAS project adopted the following definition at the occasion of the second workshop [6]:
| Implementation projects generally find that no one metadata standard will completely meet their descriptive needs. General standards such as Dublin Core must often be used alongside domain- or sector-specific standards such as MPEG-7 for multimedia and IEEE/LOM for educational resources; and new elements may be needed for local needs not covered by any of the existing standards. Recent practice distinguishes between the definition of semantics in "namespaces" (i.e. official standards) and the reuse and interpretation of those semantics in "application profiles". Application profiles are schemas that combine elements from multiple standards, perhaps with application-specific constraints such as the use of specific controlled vocabulary. |
In his “strawman proposal” and in subsequent discussions, Baker laid out a number of functional requirements for application profiles.
These requirements fall into four categories:
It needs to be noted that this is very much ‘work in progress’ and that these requirements may evolve over time, before there is a general agreement.
The concept of application profiles is rather new. What is not new is that many activities and projects have been mixing and matching metadata elements sets, and have added elements to existing sets and modified the semantics of existing elements (in the sense of defining them in the context of specific applications).
The Third SCHEMAS Metadata Watch Report [7] lists a number of examples:
During the second SCHEMAS Workshop, a number of activities presented their approach towards application profiles:
From the presentations at the SCHEMAS workshop, it became clear that many metadata schema designers go through more or less the same process in designing their metadata schema. The following steps can be identified:
In fact, what results from this process is the creation of an application profile for the local implementation, re-using elements from existing sets and adding private elements where no equivalents can be found in existing sets.
In the process described above, crucial steps are 1 and 2. In practice, they are not always taken in this order, as sometimes it can be a strategic objective to adhere to a metadata standard that is dominant in the particular application domain. This happens for example when educational projects want to use the IEEE LTSC LOM standard, or when organisations involved in geographical information consider it important to adhere to the FGDC standard.
Also, for the selection of a standard set it is important that an appropriate standard is available. In the examples above, well-known standard sets are available. If more than one standard exists for a particular domain, e.g. DCMI Education, IMS and LOM, the groups that develop the standards are often co-operating and harmonising the standards. It is not surprising that in sectors where standardisation of metadata element sets is not well advanced or where there is little co-ordination between standardisation activities (such as the industry, publishing and audiovisual sectors) the use or even awareness of application profiles is low.
Looking at the list of functional requirements formulated by Baker, it can be seen that these cover a number of the questions for which implementers may be looking for answers. The work on application profiles is, however, in its early stages. A number of fundamental questions have only begun to be asked and answers need to be found through further research and experimentation.
Much is dependent on the emergence of registries where application profiles can be published and found by others. Work in the area of registries is underway in various places, such as the Dublin Core Metadata Initiative, the Indecs project, XML.org, and, indeed, the SCHEMAS project itself.
Based on the experiences gained in these various activities, conclusions can be reached on how application profiles can help implementers to make the best use of experiences from other activities, thereby reducing the resources in the design and implementation phase, as well as helping further harmonisation to take place.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Makx Dekkers
PricewaterhouseCoopers
Luxembourg
Project Co-ordinator SCHEMAS
Makx Dekkers is a manager at PricewaterhouseCoopers Consulting, based in Luxembourg. He has a background in library automation and information networking, specialising in metadata issues. He was responsible for a series of metadata workshops in Luxemburg between 1997 and 1999, and is a member of the Dublin Core Advisory Committee. He is currently the project coordinator of the SCHEMAS project.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
For citation purposes:
Dekkers, M. "Application Profiles, or how to Mix and Match Metadata Schemas", Cultivate Interactive, issue
3, 29 January 2001
URL: <http://www.cultivate-int.org/issue3/schemas/>
|
|
