 |
Previous Chapter: 5 Applications Next Chapter: 7 International DOI Foundation
6 Policy
This chapter describes the process of policy formulation within the International DOI
Foundation (IDF), and summarises current key policies. Some areas of policy are
discussed in detail: the data associated with a DOI® name; restricted use of DOI names; exclusivity;
persistence; uniqueness; the separation of object, identifier, and metadata; use of DOI names.
© International DOI Foundation 2011
6.1 Policy formulation
6.2 Current areas of policy development
6.3 Current policies of the IDF
6.4 Data associated with a DOI name
6.5 Restricted use of the DOI System
6.6 Exclusivity and restrictions
6.7 Ensuring persistence
6.7.1 Persistence of the DOI System
6.7.2 Persistence of the IDF
6.7.3 Persistence of the resolution technology (Handle System®)
6.7.4 Persistence of the metadata technology
6.7.5 Acceptance by users
6.7.6 Persistence of the identified object
6.8 Ensuring uniqueness
6.9 Community autonomy
6.10 Separation of metadata, identifier, and entity
6.10.1 Separation of metadata and identifier
6.10.2 Separation of identifier from object
6.11 Use of DOI names by services other than the original publisher
6.1 Policy formulation
The DOI® System requires rules for its management to ensure that the system behaves in ways that are predictable and consistent.
The formulation of policy is in many ways more complex than the management and development of the technology. The way in which the DOI System is implemented can have significant impact on the way in which the intellectual-property based businesses that use the DOI System operate in the network environment. Policies with respect to metadata access and exploitation, for example, are designed to have minimum influence on the business models of Registration Agencies.
The detail of IDF policy is continually developed to meet the requirements of implementation. IDF members are fully involved in all aspects of policy formulation and have the opportunity democratically to affect its outcome.
Working group deliberations may result in written documents circulated to members, other working groups, and/or interested parties for comment. In response to member comments, further drafts may be prepared reflecting the consensus view of the membership and published in the Handbook. Significant changes in policy are presented to the Board of the IDF for approval.
6.2 Current areas of policy development
Current work on policy is mainly dealt with through the Members Working Group (MWG).
Policy development includes:
- Policies relating to the establishment and use of DOI® Application Profiles and DOI System® services. (Existing policies are included in the relevant chapters on DOI Data Model (Chapter 4) and DOI Applications (Chapter 5).
- Agreement articulating the relationship of an RA to the IDF.
- The extension of DOI System applications to new sectors and applications and the policies related to social governance in a sector. There is a desire for each major community to be self-determining, yet also a requirement for some common rules of the road (extreme granularity, complexity and eccentricity are commonplace when describing rights in a multimedia, multinational and persistent environment). In some cases natural areas of overlap (images embedded in text for example) may have policy implications; the RA and DOI System Services concepts allow for considerable autonomy in applications.
6.3 Current policies of the IDF
The following top-level policies have already been agreed by the IDF: refer to relevant chapters for details:
1. Open resolution: Once a DOI name is assigned, anyone may resolve that DOI name without charge. At least some information will always be available on resolution (see Chapter 3).
2. A DOI name can be used to identify any intellectual property entity: this includes both physical and digital manifestations, performances and abstract works. An entity can be identified at any arbitrary level of granularity (see Chapter 1.6). DOI names may also be assigned to any entity involved in an intellectual property transaction: e.g. parties, licences (see Chapter 1).
3. Intellectual property focus: The primary focus of the DOI System is on the management of intellectual property entities, but this does not preclude (for example) issuing a DOI name to an entity that is in the public domain (see Chapter 1.6).
4. Cost recovery: The costs of operation of the system should be borne directly or indirectly by the Registrants. The IDF will provide support for the costs of the system until such time as Registrant fees alone can provide this (see Chapter 7).
5. DOI names must be registered: All DOI names must be registered in the DOI System Directory. Registrants are responsible for the maintenance of state data and metadata relating to DOI names that they have registered (see Chapter 3.7).
6. Standard syntax: The syntax of the DOI name follows a standardized syntax (see Chapter 2.2).
7. Opaque (non-intelligent) syntax: In use, the DOI name is an opaque string (dumb number); nothing at all can or should be inferred from the number in respect of its use in the DOI System (see Chapter 2.2).
8. Variety of business models: The business model adopted by an individual Registration Agency is a matter for the Agency alone, so long as it complies with overall IDF policy (see Chapter 8).
9. Application Profile: Each entity registered for a DOI name will be assigned by its Registrant to at least one DOI Application Profile, either with no additional data or with some structured data (see Chapter 5).
10. Kernel: An RA must be capable of producing a Kernel Metadata Declaration (the minimum required to permit basic recognition of the entity to which the DOI name is assigned) for each DOI name issued other than the "zero" AP. Controlled values used by RAs in Kernel Metadata Declarations should be registered in the DOI Data Dictionary. (see Chapter 4).
11. No ability to search from metadata to DOI name: Reverse look-up (from metadata to a DOI name) is not a function of the DOI System itself. Reverse look-up may be offered by other services as a value-added feature. Individual applications or registration agency services may offer this service by agreement with their registrants and suppliers on commercial terms, not determined by IDF.
12. Input and service metadata: DOI System policy places no restrictions on the form and content of an RA's input and service metadata declarations, except insofar as input metadata must support the minimum requirements for supporting a Kernel Metadata Declaration (see Chapter 4).
13. No sale or re-use of DOI System data by IDF: IDF will not consolidate DOI name state data or kernel metadata for resale or re-use. This data is held by IDF solely for the purposes of permitting look-up from a DOI name to the declared metadata by any user.
14. No disclosure of usage: Usage statistics and information about individual DOI name resolution will not be released by IDF to any party. IDF will only release statistics relating to the aggregate activity of the DOI System. Records of resolution activity by DOI name are not made available. However the IDF may make data patterns and registration information available for research in the interests of e.g. Handle System performance analysis and optimization. In such cases, all data will be scrambled to render them un-interpretable and un-resolvable.
15. Escrow: DOI System data deposited with a Registration Agency will be held in escrow under contractual terms between the Registration Agency and IDF; the data will be available to the IDF in the event of cessation of the Registration Agency.
16. Data interchange between RAs: Metadata exchanged between RAs supporting DOI System services should be exchanged using an agreed DOI Referent Metadata Declaration ("RMD") using metadata elements and controlled values registered in the DOI Data Dictionary. (see Chapter 4).
6.4 Data associated with a DOI name
The simplest DOI names (such as those in the earliest implementations of the DOI System) are essentially redirection from a persistent name (the DOI name) to a changeable URL. The information associated with the DOI name in the DOI System is therefore simply the URL and relevant administrative information for managing the DOI name (zero Application Profile).
In more sophisticated applications, a DOI name may have additional associated data which help characterise the identified entity and which can be used to build various applications and services related to the identified entity. The Application Profile (AP) is a key example of such additional data. APs are used to group sets of DOI names which have similar characteristics, such as the same metadata schemas and business rules for DOI name assignment. Thus, discovering that a given DOI name is a member of a given AP is a shortcut to knowing what metadata elements can be found for the DOI name, for knowing who is responsible for maintaining the DOI name, and for any other characteristic that is common to the set of DOI names which are of that AP.
DOI name data which is not common to all members of an AP will be associated with an individual DOI name on a one-to-one basis. All non-zero Application Profiles contain a minimum of some publicly declared metadata (the kernel metadata) sufficient to provide users and applications with a basic description of the entity identified with a DOI name.
6.5 Restricted use of the DOI System
An exception to the rules on public information could be some uses of the DOI System, which are not public (either permanently or temporarily). The introduction of Restricted Application Profiles (see earlier chapters) is intended to allow this. Private use of the DOI System may have advantages either in conferring on a private scheme the benefits of interoperability, persistence, well-formed data structures, and governance structure; and in allowing the subsequent migration of private identifiers into the public realm without having to reassign identifiers with a policy or technical change which allows them to be private (and potentially switched to public) if desired.
The intention of the DOI System is the allocation of persistent, interoperable, well-formed, resolvable identifiers for public access and interoperation between parties without prior agreement: those DOI names are intended to be used by any discoverer of the DOI name. There may be instances where the benefits of a open, interoperable architecture are not appropriate for a users needs:
1. Where a wholly non-public use is envisaged, the concept of private use of DOI names may be a means of extending the adoption of the technology and principles that the DOI System is built upon and distributing costs and benefits widely. The features of the system also make it attractive for possible use in closed communities: interoperability, persistence, well-formed data structures, and governance structure persistence may be desirable within firms, or consortia, or between parties in an agreement. For example, use of DOI names for pharmaceutical research data may be very useful but public access to even basic information about what is being identified may be sensitive. The Handle System is available for private use but this alone does not confer the advantages of the DOI names structured metadata approach and rules-based governance.
2. Migration from Private to Public identifiers is a likely development which argues in favour of a single underlying system. Some DOI names may be appropriate for private allocation but later made public: for example, some pharmaceutical research data may initially be private but then required to be made public as part of an FDA filing etc., rather than migrate all the documents to a new identification scheme, for example. Hence it would be advantageous if DOI names could be allocated on exactly the same technical basis as described for public DOI names, but with a policy or technical change which allows them to be private (and potentially switched to public) if desired.
Private DOI names could take different forms, but a common feature is that something about the data that the IDF states is normally public will be restricted to a particular community. Examples:
- DOI names that were not known through the Global Handle Registry® and so cannot be resolved by those who are not made aware of a particular local resolver;
- DOI names where the kernel metadata is not made available (so a user does not know what the DOI name is associated with, but could nonetheless resolve it);
- DOI names where some of the resolution service data is not available without authorisation
A spectrum of accessibility options could be devised in this way. This definition of "private use" of DOI names equates to "not public use" of DOI names. The concept of "private use" is something that we wish to explore further, to take advantage of the DOI System as a solution across diverse information asset management problems. Any organisation wishing to consider this area in more depth is invited to contact the IDF for an exploratory discussion.
6.6 Exclusivity and restrictions
Exclusivity of DOI name registration rights covering either a specific geographic territory or a particular wide area of application in general (e.g. a sector such as "audio") will not be granted to any Registration Agency.
IDF's stance is that RAs will survive or perish as independent businesses on the basis of the added-value services and unique selling propositions they bring to offer to the market, not on the basis of DOI name registration alone, or by being granted artificial exclusivity for a wide range of activities. DOI name registration is "common infrastructure". Investors in RA businesses are naturally looking for the lowest-risk proposition possible and may feel that a grant of exclusivity conferring a monopoly is an attractive option; however, no commonly accepted models for namespace management and resolution services in general are yet established and the IDF is unwilling to cement any business models alone. In the future, globally unambiguous names will be critical, and a ubiquitous infrastructure to "resolve" those names will be essential. IDF will allow service and technology providers to overlap into adjacent domains, and leave interfaces (technical and business) open to allow experimentation with various models to happen and evolution to follow its course.
In order to provide some confidence to RA investors however, applications to become a Registration Agency will be assessed in the context of likely business implications. Where there is an overlap of the expected market or services of existing RA(s) and the applicant RA(s), each will be informed of the potential for overlap or competition and invited to address the problem in such a way as to encourage uptake of the DOI System as a whole whilst ensuring that legitimate business interests are met.
The development of DOI Application Profiles and DOI System Services allows the possibility of dealing with any necessary commercial or legal requirements for restricted access in a more precise way than granting exclusivity:
- Application Profiles may be either public (available to all RAs) or restricted: business rules of an AP may well embody a restriction (e.g. if organization X has an existing legal mandate and responsibility to publish and manage documents on behalf of a government body on an exclusive basis, and wishes to translate this activity into the digital world, it may well be appropriate to continue by devising an AP that has as one of its business rules the same restriction). The default position, however, will be that APs are publicly declared and available for use by any RA.
- DOI System Services may well be either public, or carry a de facto restriction — for example, if a particular DOI System Service is a look up on a proprietary database, then normal commercial terms for access to that database will be a requirement of use.
6.7 Ensuring persistence
6.7.1 Persistence of the DOI System
Persistence is the consistent availability over time of useful information about a specified entity: ultimately guaranteed by social infrastructure (through policy) and assisted by technology such as managed metadata and indirection through resolution which allows reference to a first class entity to be maintained in the face of legitimate, desirable, and unavoidable changes in associated data such as organization names, domain names, URLs, etc.
Identifiers must persist in the face of legitimate change. There are legitimate, desirable, and unavoidable reasons for changing organization names, domains etc. One aim of naming entities/referents is to avoid tying an entity name to a domain name, or any other piece of variable metadata. Consider the domain names/trademarks issue. The entity can be persistently named as a first class object irrespective of its location, owner, licensee, etc. Distinguishing names from locations is essential for E-commerce. It is trivially true that "all names are locations" (in a namespace), but practically, most people worry about spaces like URLs, and that's the wrong level. Naming entities as first class objects, rather than locations, enables better management of multiple instances of an object, for example.
Persistence of identifiers is something we are familiar with in the physical world e.g. ISBNs for out of print books can still be useful. Persistent identification alone is a good enough reason to adopt identifiers such as DOI names which provide a means by which potential customers can find your digital offering even if a "broken link" URL of a retailer or other intermediary intervenes.
The DOI System is an implementation of URN (Uniform Resource Names) and URI (Universal Resource Identifier) concepts, and can be formalized within these frameworks. The aim of each is to allow persistence of naming irrespective of other characteristics.
The central DOI name resolution system is managed to ensure that persistent names can be resolved to non-persistent attributes such as location. One of the problems with the World Wide Web today is that once an object is moved, anyone searching for that object may encounter an error message. This is because URLs identify a location, not an object. The DOI System, by contrast, specifies an object, not a location. Each DOI name is registered in the Handle System and can be resolved to at least one location somewhere on the Internet. When an object is moved, all a rights holder has to do is repoint the DOI name to the new location and the object can be found once more; any external party accessing the DOI name does not need to know of the change and will be taken transparently to the object. The DOI System is designed to enable registrants to make up-to-date changes easily and consistently, and to monitor errors. Additional tools (such as workflow implementations) are already being developed by outside parties, and more will follow.
Two key features of DOI names as tools that encourage persistence are:
- Indirection — one can change the current attributes without changing the name; this is difficult with URLs which have one attribute (domain name) wired semantically into the identifier;
- Separation of name from ownership. DOI names do not base the identifier on the owner, beyond the initial creation. That is, the naming authority (prefix) is used as a convenience for identifier creation but at that point becomes meaningless and the ownership of individual DOI names can be transferred without regard for the naming authority.
'Persistence' is an imprecise term: we need to talk about persistence in a more fine-grained fashion such as persisting over what conditions, and to what end. DOI names resolve to information (metadata) about the identified object in a manner intended to persist over changes in location, ownership, description methods, and other changeable attributes but not necessarily over changes in the basic utility of the object. If the object ceases to be available, the DOI System may no longer resolve to any information.
The Foundation was created in 1998; it is a Delaware registered not-for-profit organization, controlled by a Board elected by the members of the Foundation. The bylaws ensure governance in the interests of the stated aims of the DOI System and provide for the members to determine the outcome in the event of winding up. The IDF business model and plan is a self-sustaining cost recovery model. Accounts have been approved by auditors without qualification in each year. The risk of any failure of one application is spread over many companies. In the event of the IDF ceasing to exist the Board would seek to transfer the system to other parties. The IDF has substantial assets in trademarks and the existence of many applications using the specific unique combination of open standard components under the DOI System licenses.
6.7.3 Persistence of the resolution technology (Handle System®)
One of the key issues for the IDF in implementing the Handle System as the technology for the DOI System was: how do we know that the Handle System itself is going to be persistent; will it be around in 5 years ?/50 years? There are both social and technical measures to ensure this, which are relevant.
The Handle system is an open standard, so anyone can build/use a handle service; both source code and APIs are public (http://www.handle.net/). It relies of course on the top level Global Handle Registry to be in place somewhere (but so does the Internet Domain Name System assume there will always be a root server and directory around somewhere). CNRI has a commitment to funding and maintaining these; were that to fail, there are enough large scale implementers of handles to ensure that it will be picked up by someone (these include e.g. Library of Congress, the US Dept of Defense DTIC, the IDF and its constituent members, IDF RAs and their constituents (e.g. CrossRef and publishers), etc.). The Handle System Advisory Committee, containing representatives of major handle users and stakeholders, exists to enable the fair and open evolution of the Handle System in the public interest and to promote its widespread adoption. IDF has a seat on the HSAC.
Key Handle infrastructure is placed with a professional hosting company with resources to ensure 24x7 cover, mirroring machines to ensure against power outages etc. Further steps to make the system more persistent from an organizational point of view are under discussion, largely influenced by IDF requirements. Further steps in supporting technical infrastructure through mirror sites in Europe are under discussion.
IDF's agreement with CNRI allows for reversion of all DOI System data, licenses, rights etc to IDF in the unlikely event of CNRI closing or being unable to sustain its activities. IDF's agreements with RAs allow for reversion of one RAs DOI System data to IDF in the event of an RA defaulting.
DOI names are licensed implementations of the Handle System. The specific implementation, the DOI System, is protected by trademarks of the International DOI Foundation and additional specific metadata technologies and policies.
6.7.4 Persistence of the metadata technology
The DOI Data Model is based on the principles outlined in the indecs (interoperability of data in e commerce systems) project and its subsequent development. The fundamental approach of an ontology and dictionary is now published as ISO standard, MPEG-21 RDD, and is freely available for use. The implementation of this standard in an actionable and maintained dictionary is shared with other users, initially the ONIX metadata set for publisher product information, and again uses open standards, especially XML. The right to use indecs material is held jointly by IDF and EDItEUR under a perpetual assignment agreement which specifically commits the assignees to develop it "consistent with the aims and principles set out in the indecs final report" and in particular to promote its use and make the indecs Analysis freely available and to ensure that a third party does not acquire any exclusive right or license in respect of the indecs Analysis. In the event of failure of one or both, the reversionary rightsholders include International Federation of the Phonographic Industries, rights organizations (CAL, Kopiosto), etc, all of whom have an interest in the open use of the technology. The specific development of indecs into MPEG 21 was done by IDF in collaboration with major organizations such as the Recording Industry Association of America and Motion Picture Association — the MPEG work is available as an open published standard, and the intention of the consortium is to promote and make widely available tools to aid in the use of the dictionary. All the stakeholders in the metadata tools have a shared aim of common and widespread deployment.
Since the Handle system is built on open Internet standards, it does not need any formal "acceptance" to be used. As a demonstration: search Google using the terms ["Mona Lisa" Corbis]. The result will (a) show a DOI name as the first hit; and (b) you can then click on that link and use full DOI System functionality. Neither Google nor your browser need to "accept" any DOI System technology. Fundamentally DOI names are simply URIs and therefore any Internet or web technology compliant with standards can use them. If you wish to enhance applications, some tools are available, but these are optional not essential (see http://www.doi.org/tools.html.) More will be added as they become available.
Acceptance by intermediaries is not something that is a necessary step to implementation, and hence the IDF does not need to know which vendors are using DOI names and does not maintain any central list. DOI System policy is that DOI names are "free at the point of consumption"; there is no charge or barrier to resolving a DOI name. The use of DOI names in an information chain is demonstrated in e.g. http://www.crossref.org/. That system has "DOI names inside", yet it may not be obvious to outsiders that it uses DOI names. Secondary information databases such as IEEE "support" DOI names in that they are simply an entry in the database, as any search on Google under "IEEE and DOI name" will show; etc.
6.7.6 Persistence of the identified object
Just as there are legitimate, desirable, and unavoidable reasons for changing organization names, there may be equally legitimate, desirable, and unavoidable reasons for declaring that an entity identified as a DOI name is "no longer available". For example, a major publisher's policy on article withdrawal of electronic products states: "under exceptional circumstances, an article must be removed from an electronic product due to legal obligations on behalf of the Publisher, owner, copyright holder or author(s); or on moral or ethical grounds if an article with an error, or with results/statements has been found inaccurate and could be potentially damaging".
The DOI System provides a mechanism for managing this process. At minimum, a DOI name registrant is free to have the DOI name resolve to a response screen indicating that the identified entity is no longer available. This in itself will be very useful (consider for example that ISBNs for books which are out-of-print are still useful). A response such as this is certainly more useful than "404 not found". Beyond this, a publisher or RA is free to define its own policy; for example, the entity may be made available in an archive form, with a reason for the withdrawal noted.
This is closely related to issues of archiving and preservation, in which IDF has an active interest: it may be useful to develop a default or fall-back mechanism for certain Application profiles or DOI names, whereby DOI names which are no longer available through the original distribution channel of their registration are re-directed to an archival source, or to a standard source of data.
There may be specific rules for this developed within a DOI Application Profile; or there may be some generic rules, which can be devised for all DOI names. It is clear that there are many different reasons for such "out of print" digital objects: for example, an old version replaced by a new: the publisher response to a query about an old edition DOI name could be a creative marketing approach (i.e., "you have requested information on an early edition which is no longer available .." or, .." it has been superseded by the new edition but you can still obtain the older version from xyz [second hand dealer or old source]...")
IDF has concluded that it would be premature to determine a one-size-fits all mechanism; it is likely to be a result of functional requirements for the particular DOI name, including commercial issues. However this is an issue where we welcome active contributions and suggestions.
6.8 Ensuring uniqueness
The DOI System will not accept duplicate DOI names on registration. As each prefix is unique to a publisher, no two DOI names from different publishers can ever share the same prefix.
As far as is reasonably possible each DOI name should be associated with a unique item of intellectual property. RAs operating with the same or related Application Profiles may agree a method for registration agencies to check if an item of intellectual property already has a DOI name assigned to it. The action to be taken if a match is found is to be determined by the Registration Agency. There will be no requirement for a centralized database maintained by the IDF that can be queried by any Registration Agency.
6.9 Community autonomy
The requirement that the DOI System be extensible across any medium and type of content requires the ability for decentralised application building. For a managed system, this implies subsidiarity: decisions about changes should be taken at the lowest level compatible with maintaining integrity of the system. The consequence for DOI System deployment is that individual communities of interest should be empowered to use the system with a great deal of autonomy. Registration Agencies, based on market models like physical bar codes, effectively hold a "franchise" on the DOI System. In exchange for a fee to the IDF, and a commitment to follow the ground rules of the DOI System, they are free to build their own offerings to a particular community, adding value services on top of DOI name registration and charging fees for participation. Since DOI names are designed to serve a wide range of communities, it would be senseless for the IDF to impose any specific business model, or to analyse a specific community's detailed needs. However, it would equally be senseless if communities pretended the problems of managing digital information were unique to them and had nothing in common with others. If a community becomes an RA, or endorses an entity as an RA, it is free to set up any service and business model it wishes.
There is a fee for participation in the system to all RAs, based on number of DOI names assigned; nonetheless, the IDF has no say whatsoever in how RAs generate that fee (and so DOI names can be issued free or as part of a fee-bearing service). As an example, CrossRef is a service of PILA (Publishers International Linking Association), itself a non-profit consortium of some 200 publishers — both for-profit and not-for profit. PILA has its own Board, business plan, governance, etc. The only mandatory connection it has with IDF is a formal agreement for the use of the DOI System, through which it obtains licenses to the Handle System and <indecs> Data Dictionary, DOI System implementations, and the benefits of common technology. PILA uses the DOI System as one part of what CrossRef builds; the rest of the technology, and its use, is entirely up to PILA. More importantly perhaps, the influence is in fact the other way around: rather than IDF exerting control on RAs, RAs exert an influence on IDF. CrossRef is on the IDF Board, and they have representation on the IDF working groups. Ultimately, the RAs will wholly control IDF as a federation. This structure means that every RA has a say in managing the common infrastructure of many applications. The more RAs, the more valuable such collaboration will be.
A new RA is also able to take advantage of existing DOI System work and common infrastructure to save time and money and ensure future interoperability. An RA has far more influence than does an organization which developed its own "island of interoperability" by creating a separate "X-namespace" with its own rules and mechanisms: that would work within the island of X, but have no influence on what others were doing; therefore, such an organization would need gateways to Z, Y, etc.
Communities may also pool resources, developing several RAs yet using one RA as a common back-office, and this is being actively pursued by some DOI System participants at present. To encourage communities to work on relevant applications, the IDF has encouraged the formation of working groups that can focus on specific areas and may build prototypes or construct full applications: for example, CrossRef was inspired by an early IDF working group.
6.10 Separation of metadata, identifier, and entity
6.10.1 Separation of metadata and identifier
The DOI name does not carry in its syntax any information about e.g. who assigned the DOI name; it is a dumb number (an "unintelligent" or "non-significant" identifier). Any such intelligence is to be found in the accompanying metadata.
The DOI name is an opaque string. No definitive information can or should be interpreted from the number in use. In particular, the fact that the DOI name has a prefix issued by a particular organization should not be used to identify the owner of any given intellectual property — the DOI name remains persistent through ownership changes, and the prefix is unaltered.
The logic behind this is inescapable and applies to any identifier which claims to be persistent: the identifier (DOI name in this case) must be persistent; therefore, if an entity changes ownership, its identifier cannot change; therefore, the identifier itself cannot indicate anything about ownership, like "publisher". The same is true for any other aspect, which is changeable. Assigning a prefix to a publisher (or anything else; a journal, an imprint, a record label) is a one way function. It enables unique numbers to be generated, but you cannot do the reverse: "this is 10.12345 so it must belong to...." is not valid.
The suffix of a DOI name may, if the registrant wishes, be an existing identifier (e.g. an ISBN, or a SICI) which contains some intelligence in that other system. If an identifier allows the rules of construction to include the use of intelligent components (e.g. the registrant or an ISBN in the suffix) there are going to be stakeholders/users who will believe that they can interpret the identifier. Such uses may be legitimate in the namespace of that previous identifier, though not within the DOI System itself. The dangers of this must also be recognised (and this is true of any identifier system, not just the DOI System): intelligent numbers are "hardwired" with metadata rather than having the ability to have the metadata re-wired (i.e. updated). It is preferable to use well-formed metadata linked to the identifier but capable of being updated, for information concerning rights, ownership, etc. that is inherently changeable. Intelligence in the number is less of a problem if the intelligence in there is inherently unlikely to change (e.g. page number of an identified publication — hence identifiers like SICI which are intelligent). But it is problematic if you try to put in changeable information like publisher: nearly all the interesting metadata may need to be changeable ultimately (for persistent future-proofing/archiving — even (especially) things like file formats etc.) These points are fundamental to efforts such as indecs, which the DOI System has used as a basis for its metadata principles.
6.10.2 Separation of identifier from object
In certain digital objects, an identifier such as DOI name may be part of the binary bit stream, which makes up the object. However the DOI name could be stripped from the bitstream and the intellectual property could be used without the identifier. The DOI System itself does not provide a mechanism to prevent this, but third party developers are free to offer added-value features such as authenticity checks and copyright management systems that will block access if a DOI name is missing or tampered with. The widespread use of a standard DOI System will encourage the development of such systems by offering a very large potential application market.
Assigning an identifier does not of itself change any aspect of a digital object's use; it is a prerequisite for copyright management — necessary but not sufficient — hence copyright infringement could occur. However, removing such an identifier from material constitutes "modification or removal of copyright management information" and is prohibited under legislation implementing the WIPO Copyright Treaty, such as the US Digital Millennium Copyright Act.
The point of the DOI System is to identify materials for management purposes including legal management. DOI names could be used with proprietary copyright management technology in mechanisms that enforce copyright technically. We view this as an added value use of the DOI System.
There are application possibilities with public key infrastructure and the Handle System protocol, which offers trusted resolution, as a possible infrastructure that may be usable for DOI names. Of particular interest for commercial uses, the Handle technology includes two features suitable for trusted transactions:
- The Handle System allows ad hoc trusted resolution across the entire distributed system. There is some overhead involved in utilizing this feature.
- The Handle System supports distributed trusted administration. The permissions are at the handle (DOI name) level, not at the server level. Again, this is especially useful for a distributed system. If you have administrative privileges on a given DOI name, you don't have to worry about where or how many or even who owns or runs the servers.
- For further information refer to http://www.handle.net/papers.html
We have no intention of replacing existing value-added copyright protection measures (either proprietary or open standard); rather we wish to encourage their use with DOI System entities by providing a readily interoperable platform and set of policies.
6.11 Use of DOI names by services other than the original publisher
Just as booksellers use ISBNs but don't assign them, any party in the information chain must be able to use "actionable identifiers": the DOI System is not a "publisher-only" system. Identification is logically a separate function from rights assignment, hence the rules of an Application Profile need not specify that only the rightsholder may allocate an identifier. Having a DOI name assigned to an entity cannot, of itself, certify anything about the copyright status of that entity. DOI names may be assigned by third parties; and most certainly DOI names may be used by third parties. Rules about who may and may not assign an identifier within an Application Profile may be part of an Application Profile specification.
The digital world does not imply a single worldwide accessible copy, disintermediating all but the publisher. In fact, the opposite is true: information on a network is widely distributed, and whilst a rightsholder (DOI name assigner) could in theory maintain a central database, the rightsholder cannot control every mention of his intellectual property, or enforce a single gateway to the material. There are many occasions where a rightsholder will want to encourage widespread access to his material by others independently of his control (but under specified conditions), to maximise value whilst limiting misuse. A useful comparison is the standard book number, the ISBN, which is used by millions of booksellers and libraries every day; those uses are not linked in any way to publishers' databases; they do not go through a publishers "gateway". Yet many added value services use the ISBN as a key to other databases. Customers and users need this consistent identification scheme to enable them to go to material with confidence through a variety of services, without having to check back to the original publisher every time they want to navigate on the network. DOI names can be used just as physical bar codes are in the nondigital world: as a means of automating the supply chain.
Even with a simple implementation such as single URL resolution, the DOI System may be useful in the same way as this ISBN example. But there are many more interesting possibilities, which can be envisaged too:
- Using multiple resolution, one or more of the resolution options could be to third part organizations, either for provision of services or for provision of content on agreed terms.
- The use of existing DOI names with local resolution technologies (e.g. OpenURL) allow for automating links to an "appropriate copy", a service which might be offered or facilitated by an intermediary or third party service. Having identified a referent generically with a DOI name, I need to locate an appropriate source to which I have access rights, or on some other basis (this too could have a DOI name).
- DOI names could be assigned within an Application Profile by service organizations, either on behalf of rightsholders or for entities where the original rightsholder is inappropriate (as a hypothetical example, out-of-print books lacking ISBNs).
- A record created "about" some other entity may itself have value (for example, a text synopsis or abstract). That record might itself be assigned a DOI name, which has a relationship to the original work. The key to describing this relationship between two entities is metadata. The indecs Data Dictionary offers formal mechanisms for expressing these relationships as part of Application Profiles.
- Many organizations prefer to rely on proprietary identifiers assigned by their supplier (for example, a wholesaler or distributor) who they know will have managed this task consistently, rather than rely on the identifiers issued by the original providers which may not be comprehensive. A similar situation may well exist between service organizations using DOI names and their customers. DOI names can of course resolve to other DOI names or to an internal service organization identifier.
Previous Chapter: 5 Applications Next Chapter: 7 International DOI Foundation