A Digital Object (“DO”) consists of one or more sequences of bits, or sets of such sequences, incorporating a work or a portion of a work or other information in which a party has rights or interests, or in which there is value, each of the sequences or sets of sequences being structured in a way that is interpretable by one or more computational facilities in a network, including in particular the Internet, and each digital object having an associated unique persistent identifier. DOs are sometimes referred to as “Digital Entities.”
There are no theoretical limitations to the DOA that we are aware of. Should we learn of any such limitations in the future, we would plan to amend the specifications accordingly. Implementations of the DOA will naturally have limitations, depending on the purpose to which those implementations are intended to serve or the specific technologies used in those implementations.
By a given DO, we assume that means one whose identifier is known. Resolving that identifier will provide the state information that a client can use to get to the appropriate DO Repository, such as its service information (e.g., its IP address or a DNS name). If the information is not stored in a DO Repository, the state information (entered by the creator of the DO) should indicate how to access it. For example, if it is a web page, one would expect the URL to be provided.
An identifier in the DOA is structured in the form of a prefix followed by a “/” and then a suffix. Informally, these are known as “handles”. A suffix can be any string represented in Unicode 2.0 and encoded using UTF-8 at present. The prefix consists of a numeric value, followed by zero or more numeric values, each separated by a dot (“.”) called a delimiter. “35.1” is a hypothetical example of a prefix and “35.1/abc” is an example of a handle. There is a global handle registry of one-delimiter prefixes (e.g., 35.1) in the above example; however, the DOA may also be implemented on a peer-to-peer basis without the need for a global registry. An individual or organization authorized to provide identifier/resolution services (called local handle services), and to whom 35.1 was allotted for this purpose, would have this prefix made known to the global handle registry. Let us assume a user wants to resolve the handle 35.1.HQ/abc (in this case, the two delimiter prefix 35.1.HQ has been derived from 35.1). The set of steps would be as follows. The client software would first find the local handle service associated with the prefix 35.1 from the global handle registry and ask that local handle service for the state information associated with 35.1.HQ/abc. This returned information is known as a handle record. If that local handle service has the information, and it is publicly available, it will return the handle record. If it is not publicly available, the client software will learn that status. If another local handle service maintains DOs that start with 35.1.HQ, the first local service will redirect you to another local handle service that is responsible for DOs starting with 35.1.HQ.
The DOA is publicly available in the same sense that the rest of the core Internet architecture is publicly available. Various service providers charge for their respective services as is the case with the rest of the Internet. For example, organizations that decide to operate local handle services must be allotted a prefix by one of the several Multi-Primary Administrators (“MPAs”) that operate the public facing services of the global handle registry, each of which will require a service agreement or equivalent to be entered into. Some MPAs may have membership arrangements that take the place of individual service agreements. While not required, there is usually a nominal fee associated with the service or membership. One can run a DO repository, DO Registry, web service, or other database service by acquiring the equipment, or contracting with a third party to host the relevant information, based on whatever service strategy makes good business sense to the individual organization.
As is the case with the rest of the Internet, there are various summary documents available describing the DOA and its origins going back to the 1980s, as well as several specifications or more detailed descriptions of parts of the architecture. A suggested reading list is available here.
The DOA as an architecture is not encumbered by intellectual property (IP) constraints. Individuals or organizations that develop software implementations of DOA components may impose IP constraints on such implementations. Users will usually have a choice of implementations to use.
Questions have often been raised about the patent status of the DOA in light of a U.S. patent granted to Corporation for National Research Initiatives (CNRI), titled “System for uniquely and persistently identifying, managing and tracking digital objects” (U.S. Patent No. 6,135,646) for what later became known as the DOA, and which highlighted the use of unique persistent identifiers associated with digital objects, a resolution mechanism, and repositories for information management. This patent expired on October 22, 2013. This means that the subject matter claimed in the patent has been dedicated to the public. Again, the Digital Object Architecture is in the public domain.
A related patent application, titled “Authenticating and using digital objects” (US 20030233570 A1), that may be of interest in the context of discussions about “blocks” and “blockchains” as “digital objects,” was filed by CNRI and later abandoned when the claims were rejected as covered by the expired U.S. Patent No. 6,135,646.
The word “handle” is a generic term used within the DOA to refer to a DO identifier. The more formal term is “digital object identifier.” In the late 1990s, a group of publishers formed the International DOI Foundation (IDF). The IDF branded their use of handles as DOIs and added additional features to create what they call the DOI System. DOI is a trademark of the IDF. So while all DOIs are handles, all handles are not DOIs.
CNRI founded the DONA Foundation (“DONA”) in Geneva, Switzerland on January 20, 2014. As set forth in the DONA Statutes, the purpose of DONA is the management, software development and other strategic services for the technical coordination, evolution, application and other use in the public interest around the world of the DOA, with a mission to promote interoperability across heterogeneous information systems. Within its purpose, DONA is responsible for the overall administration and stable operation of the GHR.
The DONA Foundation has now assumed overall responsibility for the evolution of the DOA, including its core components, and for the development and deployment of reference software implementations of these components, where appropriate. There may also be software developed by DONA working with other organizations to enable interoperability with different information systems in the future. This will be accomplished by first focusing on documentation to update earlier informational RFCs (3650, 3651 and 3652) published by the IETF, and to update the digital object interface protocol previously made available by CNRI (and now described in ITU-T Recommendation X.1255 as the “digital entity interface protocol”). In addition, DONA will provide a technical manual for the installation of certain implementations of DOA components, starting with local handle system software for use by MPAs. The MPAs may also release compatible implementations of their own.
There is no present intent to add semantic capabilities to digital object identifiers; however, the DO Registry/Repository components make use of keywords and other search mechanisms that are usually based on the information represented in digital form and structured as a DO, in particular information contained in metadata registries.
As an architecture, the DOA is focused entirely on information management in the Internet or other computational environments. It is in the interest of all parties that rely on it to keep it from fragmenting. So far (other than adversarial attempts to undermine the Internet via use of spam, viruses, phishing efforts and cybersecurity related activities) the Internet has maintained its integrity due to the desire of the participants to achieve that outcome. While this is not exactly the same set of concerns as might exist for various implementations of DOA components, and their interaction as part of the core DOA-based infrastructure, the end result of coherent operation rather than fragmentation (including interoperability with other different information systems) is the desired end result.
One is the use of identifiers to enable direct interaction with DOs (rather than with a technical feature of a system such as a file in lieu of its contents). The Digital Object Interface Protocol (DOIP) available here enables all DO Repositories to interoperate independently from the storage system implementation in use. Implementations of DOA components incorporate security via an intrinsic PKI capability, where each user, system, piece of information (and perhaps other network resources) has its own unique identifier. The role of the identifier/resolution component of the DOA is what enables persistence, in the face of information that changes location or is mutable over time, provided that the parties responsible for the information itself continue to make it available by means of its identifier.
None really, as long as they are implementable. This is a modular aspect of the registry implementation. As new and better search algorithms and associated strategies are developed or invented, they can be incorporated in later versions. The architecture places no constraints here, but most implementations will have to balance offered load and search efficiency with the desirability of new approaches.
The basic underlying technologies involve communications, computing, and storage. The DOA is basically agnostic about reasonable technical choices here. As has been the case with the rest of the Internet, which relies on the same three basic underlying technologies, the Internet architecture has worked over a scaling factor of about a million or more in each technology and continues to scale beyond that. The Internet architecture was (and is) about making things work together regardless of what they are. The DOA has the same set of attributes, but at a finer level of information granularity. As communication, computation and storage continue to evolve, the role of the DOA should also be essentially independent of those evolutionary developments.
Blockchain technology first caught the public imagination with the introduction of bitcoin in the late 2000 time frame, and has subsequently been considered in various forms by the financial community and others. It should be noted, however, that the origins of this technology, in particular, the chaining of operations on units of information in digital form, called packages, containers or more generally digital objects, find their roots in communications work that took place over a half century ago, and from research and development efforts in computer technology (particularly programming languages such as LISP) going back almost as far. In May 1997, around 45 companies expressed support for this technology in a Cross-Industry Working Team (XIWT) report: “Managing Access to Digital Information: an Approach Based on Digital Objects and Stated Operations.”
While there are many approaches taken or underway with respect to blockchain technology, it is asserted that the technology has the apparent virtue of having no central authority (although a “centralized” resolution mechanism would likely be required), and that changing transactions is virtually impossible. This is best understood as a way of managing digital objects: conceptually, a block is a digital object. Blocks are linked together to form the blockchain; and the linking usually involves hashing them together in a specific structured way. The DOA places no restrictions on the elements of a digital object, so hashing and linking them is clearly permitted. The blockchain needs an identifier in order to specify to which blockchain a block is to be added; and, since digital objects can contain other digital objects (a repository being an example of such a digital object that contains other digital objects), a blockchain may clearly be viewed as a digital object as well.
An article entitled: “Blocks as digital entities: A standards perspective” was published in Information Services & Use, vol. 38, no.3, pp. 173-185, 2018; and the article is available in the Internet at: https://content.iospress.com/articles/information-services-and-use/isu180021. The authors present a general overview of the origins and current status of the Digital Object Architecture and share observations about a blockchain as a particular way to configure a digital object.
Switzerland was widely viewed to be a neutral venue, and many relevant standards bodies have a presence in Geneva.
In accordance with the DONA Statutes and By-Laws, there is a Board of Directors whose members serve in their personal capacities; it reflects a diversity of perspectives. The Board can grow to as many as twenty-five (25) individuals and is intended to be multi-stakeholder in composition. The MPAs are entitled to representation on the Board; however, the DONA By-Laws provide that no more than one-third of the Board shall consist of individuals designated by the MPAs and elected by the Board. Decisions by the Board are normally made by consensus, except that, in unusual circumstances, the Chair of the Foundation can call for a vote, if deemed necessary.
As a Swiss foundation, DONA has no members and the governance of the foundation is driven by its Board of Directors. In accordance with the DONA Statutes, decisions about additions to the Board of Directors are the responsibility of the Board. The need for changes to the Foundation Policies & Procedures is also determined by the Board.
The current Board involves a diverse set of individuals from Europe, Africa, China, the United States, and Russia. The initial eight Directors were selected by the Founder, i.e., CNRI, but, going forward, the general criterion is to have broad global and diverse representation, as determined by the Board. In considering specific criteria, the Board has stressed that, whenever possible, new candidates should have significant technical knowledge in areas relevant to the DO Architecture. In considering potential candidates, the Board has also suggested that persons having substantial industrial experience be included, keeping in mind the need for geographic balance and a multi-stakeholder approach.
DONA has responsibility for the overall administration of the GHR, which interfaces with the public via one or more organizations called Multi-Primary Administrators (or “MPAs”) that are authorized and credentialed by DONA. To become an MPA, an organization, after being designated as an MPA by the DONA Board, must enter into a Multi-Primary Administrator Service Agreement with the DONA Foundation, which incorporates by reference the DONA Foundation Policies & Procedures for the GHR (“Foundation Procedures”). Each MPA has its own business model, which complies with the Foundation Procedures; and the MPAs coordinate with each other (and with DONA) in the operation of the GHR.
The intent of the Foundation, as determined by its Board of Directors, is to authorize and credential an initial set of twelve MPAs based on multiple factors such as (i) existing administrators, (ii) proposed representation of relatively large existing communities, (iii) strong early adopters of the technology, and so forth. In a few years, the Board will reevaluate this decision in light of experience with the deployment of the GHR on a multi-primary basis.
Each MPA operates its own GHR Services in accordance with the Foundation Procedures and coordinates its GHR Services with other MPAs and DONA in the distributed operation of the GHR on a multi-primary basis. In providing its GHR Services, each MPA shares with each other MPA and DONA critical GHR structural information to assist users in locating a provider of a local handle service that can help to provide assistance in the form of desired handle records, if such records exist. An MPA also interacts with individuals or organizations interested in being authorized to provide identifier and/or resolution services, i.e., local handle services, and be allotted one or more prefixes derived from the MPAs credential for this purpose (e.g., 35.1 or 35.1.ABC, where “35” would be the credential allotted to a particular MPA by DONA).
Funding for the administration of the GHR and other Foundation activities comes from annual fees paid to DONA by the MPAs. As decided by the DONA Board, software development, outreach activities and pilot projects in the future may require additional funding sources.
As a foundation constituted under Swiss law, the DONA Foundation operates under the supervision of the Swiss Federal Authority for the Supervision of Foundations. The main objective of the supervision of the authority is to make sure that the Board complies with the purpose clause of the foundation and that its finances are kept balanced. The authority does not interfere with the management of the foundation.
CNRI was the Founder of DONA, which was constituted under Swiss law on January 20, 2014. CNRI entered into an Operational Framework Agreement for the GHR under which CNRI transferred authority for the overall administration of the GHR to DONA, as well as the responsibility for the further development and evolution of the DOA in the public interest.
The DOA is an architecture that has been made available in the public interest. Specifically, the DOA is in the public domain and any individual or organization may develop software implementations of the components of the DOA. To date, CNRI has developed and deployed reference software implementations of the components of the DOA; and it is likely that implementations have also been made by others. While CNRI has chosen to make its software generally available under public licenses that entail no royalty payments, others may choose to provide their software subject to royalty payments.
Once an organization has been authorized and credentialed as an MPA, they will usually ask DONA or one or more of the previously established MPAs to advise or otherwise assist them. Further, during an initial experimental period, a newly authorized MPA agrees to operate its GHR Services in experimental mode separate from any existing operational services and to collaborate with DONA and any other participating MPAs to validate, characterize, and enhance the operation of the GHR.