 |
Previous Chapter: 4 DOI® Data Model Next Chapter: 6 Policy
5 Applications
This chapter introduces the concept of DOI® Application Profiles (APs) and associated Services. A DOI® Data Model and Application Programming interface allow application developers to work independently of the underlying technologies. Management of APs and Services is discussed.
© International DOI Foundation 2006
5.1 Introduction
5.2 Basic Approach: DOI® names, DOI APs, and DOI System Services
5.3 Managing APs and Services
5.4 DOI® Data Models and APIs
5.5 Management and administration of APs and Services
5.5.1 Registration of APs and Services
5.5.2 AP and Service Management
5.5.3 Ownership of Intellectual Property in DOI APs
5.6 Benefits
5.1 Introduction
DOI names can do more than provide the current location of an object; they can also provide or point to any useful information about the object. This information can include any type of descriptive metadata and any type of service related to the object, e.g., rights clearance or alerting services. Building applications to take advantage of this extended information requires that it be standardized in some way and that the DOI name owners have some way to manage all of this data.
This chapter introduces a few specific mechanisms as well as a data model and some policies, all aimed at making this extended DOI data both understandable and manageable.
- Application Profile (AP) -- a group of DOIs with some shared characteristic(s). This grouping will be used to connect DOI names to Services which are common to the group.
- Service -- a specific transaction that can be performed on or with a DOI name.
- The DOI Data Model defines the way in which DOI names, Application Profiles, and Services relate.
- Lastly, multiple APIs have been built which allow application programmers to tap into the data model, using DOI APs and Services within their applications, without understanding the details of how they are implemented.
This approach has been proven in a concept trial used to build the DOI name/handle plug-in for Adobe Acrobat Reader (see the DOI.ORG web site).
5.2 Basic Approach: DOI® names, DOI APs, and DOI System Services
Each DOI name is associated with one or more Application Profiles, and each AP is associated with one or more defined Services.
DOI names are grouped into Application Profiles in order to manage their association with services. Any DOI name may, potentially, be associated with any number of services, e.g., extended metadata may be obtained by sending the DOI name in a certain manner to a certain address, a price quote for a translation service can be obtained here, related documents can be found there in a certain way, and so on. And the specifics of those services and the connections between a given DOI name and a set of services will likely change over time. Managing that complexity at the level of each DOI name, in a world of many millions of DOI names, is not tractable. Grouping DOI names into named Application Profiles and further associating APs with named DOI system Services allows simple changes, e.g., the address of a service location, to be done once and to reflect back on many DOI names.
A service is simply a defined result from a defined action, i.e., do X and the result will be Y. This will frequently involve specific servers in specific locations on the network but we also include more abstract notions such as a defined method for comparing dates in documents with dates in DOI name records. This involves a server but the client is then critical for finishing off the 'service.' We are using it in more or less the same generic sense as Web Services and the Grid Service architecture, but what we mean is specific to DOI names and is not restricted to either of those models.
One of the services, possibly the only one for some DOI names, is the provision of kernel metadata (see Chapter 4) for each DOI name. Other sets of metadata may also be available for some DOI names and this, as with other services, would be known through the inclusion of a given DOI name in an AP and the association of that AP with the given service. Each AP is itself identified by a DOI name, e.g. DOI:10.profile/7, and it is that DOI name, instead of each of the content level DOI names, that will be directly associated with the set of services relevant to each member of its set. Each of the registered services will also be identified by a DOI name, e.g. 10.Service/3. Associated with each service will be a natural language description of the service plus one or more interface descriptions (e.g., Interface Definition Language, Web Services Definition Language, or bindings and other information needed for using the service). The same service could be used by multiple APs through the simple mechanism of registering the service under multiple APs, just as a single AP will be 'used' by multiple DOI names.
APs may themselves be grouped into APs, i.e., they can be nested. This makes it possible to group them together for greater levels of indirection yet still maintain the flexibility to create new groupings and associations as needed. One of the challenges of applying the DOI AP and Service model will be finding the right level of granularity for the AP groupings. In some cases it may be that all DOI names from a certain producer may be grouped together in reasonable anticipation that any service that would apply to any of them would apply to all. In other cases the right level might be one particular product, e.g., a specific journal, again in anticipation that this will represent the group of DOI names for which deals will be made and services designed.
Granularity is also an issue in the creation and identification of services. If the same service, where 'same' refers to the function as opposed to the structural specifics, is implemented by multiple service providers and used by multiple APs, it should none-the-less be identified as a single service whenever possible. The details of the profile/service association can carry the information needed to go from the DOI to the appropriate version of the service. Consider, for example, a rights clearance service in which the same input, a DOI name, yields the same output, e.g., current conditions attached to re-use. If multiple providers make that service available it would be advantageous to DOI System users if third party applications were able to offer all variations of the service in a transparent manner, going from one vendor to another as needed without any action on the user's part.
5.3 Managing APs and Services
The IDF will maintain the registry of APs and Services, i.e., it will serve as the registrar for the 10.AP and 10.Service prefixes just as the current RAs maintain the registry for the 10.1001, 10.1002, etc. prefixes. That relationship is summarized in the following table:
| Type of DOI | Create and Maintain | Registrar |
| Creation (Content) DOIs | Content Providers | RAs |
| APs | RAs | IDF |
| Services | RAs* | IDF |
(Although all these entities have DOI names, APs and Services are assigned DOI names simply as a management mechanism, i.e., attributes of the Creation DOI name rather than as meaningful "containers" in their own right; we do not think it useful to treat APs as self-standing entities other than for internal management purposes -- so we do not consider APs for DOI APs, etc.)
Further, the key connections between DOI names and APs and between APs and services are regulated by the RAs through the process of registering and maintaining the content DOI names and the AP DOI names.
*Note that creation of services by organizations other than RAs would require additional mechanisms and rules for registering services; initially services will be created only by RAs or in collaboration with RAs or IDF.
In creating a new AP an RA could choose to associate it with existing registered services or could create and register a new service or services with which to associate it. Existing APs can be used by new RAs, but the AP will continue to be maintained and governed by the RA which registered it in the first place. Contractual agreements could, of course, be put in place to manage the evolution of a shared AP, but only the original RA would be the manager of that piece of the infrastructure.
As illustrated in the following section, both APs and Services carry their own descriptions within the system. These descriptions are currently open-ended natural language explanations of the intent of their developers, i.e., what sort of DOI names are in this AP and why and, for Services, what will happen if a particular binding is used to instantiate this particular service. In order to both better manage and understand APs and Services it will be necessary to describe them with much greater precision. The proposed approach to that precision is to describe both APs and Services using DOI names for terms registered in the iDD (see Chapter 4). Thus, future versions of the Data Model will allow application builders to more precisely understand the intended relations between DOI names, APs, and Services and potentially link them together directly through the iDD taxonomy.
None of this constrains the creation of Services in any way. One could imagine these mechanisms being used to point at specific servers on the Net that would provide a defined service, e.g., rights and permissions information for the identified entity, and one could imagine a service that provides software for a client to use at its discretion, e.g., apply this script to validate the signature attached to any entity of this AP.
These mechanisms provide a great deal of flexibility but it should be noted that there is little way for any client to bootstrap its way into understanding what to do with completely new services: either a software client has been programmed ahead of time to know what to do with a Service or it hasn't and won't know what to do with it now. The bindings and descriptions that are associated with Service DOI names are intended as reference material to be consulted by application developers in designing and building applications. The variety of Services will be broad and implemented in a great number of clients; it may be difficult to build an application capable of bootstrapping its way into a Service that was not explicitly known to the application's developer.
5.4 DOI® Data Model and APIs
Up to this point in DOI System evolution, most technical plans and descriptions, with a few notable exceptions, have been made in terms of the underlying Handle System®. The current level of complexity, where DOI names mostly resolve to single URLs, has made this possible. The added complexity of APs and Services, however, requires us to formally define a separate DOI System layer. This is required both for usability and data integrity. As we add procedures and structures for layering DOI System information over the Handle System it becomes increasingly important to define those procedures and structures in a separate layer. The Handle System is still there and its functionality is what enables the DOI System layer, but understanding and using the system will require building and using abstractions such as APs and Services.
Figure 1 shows an abstract view of this model, which has also been referred to as the Application Profile Framework. DOI names are linked into Application Profiles. Any single DOI name can be a member of multiple APs. Each AP can be linked into multiple Services. That linkage is to one or more specific instances of a Service. Each defined Service can be made available in multiple ways, referred to as instances. Using the rights clearance example above, and working from right to left in Figure 1, a rights clearance Service would be precisely defined and would be made available from multiple vendors using a variety of specific approaches. Each of those approaches would be an instance of the rights clearance service. Each of the instances would be usable by all of the members of one or more APs. This makes it possible to add a Service to many DOI names by adding that Service to relatively few APs.
Figure 1: DOI Application Profile Framework
This framework is implemented in the handle system, using DOI names for both APs and Services and linking them together through typed handle values.
APIs (application programming interfaces) have been created that abstract out the details of the handle system implementation and make it possible to administer the structures and to use them in applications while ignoring the details of the implementation. They provide "hooks" down into the handle system without directly manipulating the handle records directly. This not only simplifies the process but would allow the mapping to be altered at a future date without breaking existing applications.
Figure 2 shows the DOI data model from the API perspective. Here the details of the way in which DOI names, APs, and Services are connected is hidden from the application developer who is provided instead with methods for retrieving APs and Services associated with a given DOI name.
Figure 2: DOI Application Profile Data Model
The approach taken so far has been to develop a Structural API which discusses DOI names, APs and Services for (object-oriented) programmers; and a Service API which ignores APs etc and simply asks "tell me what the services are." The top box in figure 2, for example, shows all of the connections between a single DOI name and its related APs and Services. These could be derived from the handle system by starting with the DOI name and following the links to the associated APs and then following the links from the APs to the associated Services. The APIs take care of this and simply return either the APs and Services or, in the case of the Services API, cutting right to the chase and just returning available Services. Details of the API are currently available to IDF members only while it is still in an advanced prototype stage. It will be made freely available at a later date.
5.5 Management and administration of APs and Services
5.5.1 Registration of APs and Services
All APs and Services must be registered with, and so implicitly approved by, the IDF. The registration of both APs and Services is restricted to IDF Registration Agencies. This does not preclude third parties from providing DOI System Services or defining APs, but they have to do so through agreements with one or more RAs. Similarly, multiple RAs could collaborate to provide services associated with a given AP. The business model and specific arrangements are left to the individual RAs to develop as they see fit and the IDF will control only the registration process.
Services, by IDF policy, should be as consistent as possible across all DOI names, e.g., kernel metadata for all DOI names should be obtained in the same manner even though the schema and network locations vary. Part of the reason for enforcing a centralized registration process is to prevent essentially the same service from being offered under multiple names, and so confusing application builders and artificially impeding potential DOI System use.
All current DOI names resolving to a single URL and nothing else are now defined as in the "Zero Application Profile", AP type 0 (10.profile/0). That single URL will be known as the Primary URL and will continue to serve its current purpose of default web location to return for the identified entity.
Any DOI name which is associated with an AP other than 0 will, by policy, be associated with at least the "Base AP", 10.profile/1. The base AP will carry three pieces of information, either directly or through indirection: the RA which registered the DOI name, the Kernel Metadata Declaration (KMD), and the Primary URL. Other than being mandated by policy, 10.profile/1 will function as a normal AP.
One of the services linked to 10.profile/1 will be provision of the Kernel metadata with as much commonality as possible across formats and protocols, such that a core group of clients will be able to retrieve and parse the Kernel metadata across all DOI names.
No Registrant will be compelled to register any intellectual property entity in a particular DOI Application Profile. All entities must belong to at least one AP (of which the simplest should be the Base AP); entities may belong to many APs, so long as the Registrant complies with any rules that may be associated with each AP.
5.5.2 AP and Service Management
While some APs and Services may be relatively small in terms of numbers of affiliated DOI names and number of organizations involved, it is likely that some set of both APs and Services will develop "user communities" that will require governance mechanisms. The RA which registered the AP or Service may alone decide to act as the governance body for the AP, or may delegate this to a third party.
Rules of procedure for the management of the DOI-AP could include issues such as access to and exploitation of metadata, as well the implementation of applications based on the metadata. The procedural rules could also cover the question of who shall be permitted to register a DOI name and to manage the associated data, within an AP.
The development of the technical, procedural and commercial rules for a new AP or Service is the responsibility of the organizations that are seeking to register them; however, it is essential that the development work be done in close co-operation and dialogue with the IDF.
The decision to develop a new AP or Service, versus extending the use of an existing schemes, is based on functional granularity: a new AP or Service should be developed when there is a reason to distinguish it from one already in existence. The IDF will examine each proposed registration with this question in mind. The IDF's primary guideline will be to minimize the number of similar APs and Services, while maximizing the applications of the DOI System that are available to registrants and facilitating and encouraging the development of new applications. The IDF will encourage dialogue between organizations with similar requirements, to explore the potential for convergence among various APs and Services.
Mapping of AP metadata schemas, as planned in the definition of APs, to the indecs Data Dictionary will ensure interoperability between the metadata schemas of different APs, thus allowing the same entity to be registered in more than one AP without metadata conflicts. A DOI name registered in more than one AP will therefore have available to it, potentially, the metadata consisting of the union of the individual APs. The practical business implications will however need to be discussed and a role of IDF may be for example to encourage of interaction of AP agencies or users.
An IDF registry will list and summarize APs and Services. This will allow RAs and other interested parties to check existing APs and Services before creating new APs or Services. A simple generated list of registered AP and Service DOI names and their natural language summaries will suffice in the beginning and more complex arrangements will be made as the need arises.
While there is by definition only a single RA for each DOI name, that DOI name can still be associated with services from multiple RAs. The management of this will be left to bilateral agreements not centralized through the IDF. Policy implications also follow from this: for example, if there is any cross charging between RAs for use of "their" DOI names in some service provision, this will be left to bilateral agreements not centralised through IDF.
5.5.3 Ownership of Intellectual Property in DOI APs
Any intellectual property that may exist in a DOI AP, as defined within the context of the DOI System and the iDD, is the property of the IDF. The IDF will license the use of those APs and Services to any Registration Agency without charge. However, in recognition of the costs involved in defining an AP and the applications which the AP enables, the IDF may consider a negotiated period of exclusivity for a Registration Agency, before others are licensed to use any particular AP.
There is no compulsion on Registration Agencies to license the use of any services that they may have developed or to license their intellectual property in any context other than that of APs.
Any other organizations may, with the permission of the IDF, choose to adapt either the metadata schema or the commercial and procedural rules of an existing AP to use in another AP.
5.6 Benefits
DOI names identify different kinds of entities with different attributes and different related services which may vary over time; and so the core DOI name resolution mechanism must be able to show those differences and point to those services, either directly or indirectly, as they appear.
The purpose in creating Application Profiles and then linking each individual DOI name to one or perhaps more of them is to allow users to determine what can be done with a given DOI name. An application is able to recognise that "this is a CrossRef Citation DOI name and so it is reasonable for me to use it in a rights clearance query or to offer some human user the option to do so". It can use all such DOI names in the same way, directly or indirectly through some service which knows how to use that structure.
DOI Application Profiles are a grouping mechanism, and through combination with resolution the AP also becomes a level of indirection for services. So if the Acme Registration Agency registers one million DOI names all of Application Profile 9 and a year later adds one more service to the three services that were available from the start, only the single 10.profile/9 record needs updating, and not the one million DOI names, which are already tagged with AP9.
Similarly, additional services may be made available to existing APs: when a new service is created it will not be necessary to change every DOI name to point to that service; nor will users have to find out about the service; the Application Profile of each DOI name is the key to making that happen: add the new facility (service) to the Application Profile record and all of the millions of DOI names associated with that AP inherit the new facility.
The evolution of this approach will include more precise definitions of both APs and Services via linkage to the iDD. This will greatly aid in the decision of whether to use an existing AP or Service or to create anew and will enable application builders to more easily understand the purpose of a given AP or Service.
Previous Chapter: 4 DOI® Data Model Next Chapter: 6 Policy