FAQs

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.”

Please refer to the details provided here. 

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 to provide 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 in collaboration with other organizations, which will enable interoperability with different information systems in the future. DONA released the DO-IRP v3.0 Specification as a companion to the Digital Object Interface Protocol previously made available by CNRI (also described in ITU-T Recommendation X.1255 as the “digital entity interface protocol”). DO-IRP v3.0 is a replacement for the three RFC's (3650, 3651, and 3652) previously published by the IETF.

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 DO's [rather than with a technical feature of an operating system (e.g., a file) in lieu of the actual content]. 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, such as the Handle System, 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.