No two standards are the same…
From media archives to libraries and museums, each sector in which Adlib operates has its own standards: the archives have ISAD and EAD, the libraries MARC and FRBR, and museums use Spectrum, CDWA (Lite), LIDO and ObjectID. In addition, there are a plethora of technical standards: SQL, XML, OAI-PMH, UNICODE, SRU, SRW…I could easily fill a page with even more acronyms.
So, does this mean that the hapless Adlib user is expected to familiarise him or herself with all of these standards? Thankfully not: your Adlib application brings together all the relevant standards under one roof. Or, as we prefer to call it, “Standards by Stealth”.
Adlib owes much of its global success to the fact that all of these standards are supported. As an Adlib user, you automatically work with standards and can benefit from a wide range of options for sharing data – managed in Adlib. The latter feature is the main reason for using standards. It ensures that your own data can be freely exchanged with other systems and are not locked into Adlib. Conversely, data contained in other systems can be effortlessly shared with and read in Adlib.
Occasionally, Adlib users can instantly tell that they are working with a standard, because this is displayed on the input screens. A good example is the ISAD(G) standard (International Standard for Archival Description) in Adlib Archive. This application displays “ISAD(G)” on the screens. More often than not, however, Adlib users won’t even notice that they are working within a standard. For example, Adlib Library works with user-friendly input screens and user-understandable field names instead of MARC’s customary number designation. Library data can be exported effortlessly (from version 4.4 on via the export wizard) from Adlib to e.g. MARC-XML (MARC21), including the numeric MARC tags.
Data managed in Adlib can occasionally also be made available to third parties across multiple standards. For example, the Dublin Core standard can be used to present data from archives, libraries and museums. Museum data, for instance, can be expressed in LIDO (Lightweight Information Describing Objects). Archival data imported in ISAD fields can be exported effortlessly (from version 4.4 on via the export wizard) to EAD.
The flexibility of Adlib enables users to decide which standard to apply to which fields. Either because they have introduced new fields in Adlib, or because they wish to express certain fields in the requested standard. This is particularly desirable for a commonly used standard such as Dublin Core (DC). DC includes a general Subject field. The data that an organisation wishes to make available from Adlib is often organisation-specific/depends on the type. As a result, standard export to DC is common. It may interest you to learn that Adlib was closely involved in compiling/drawing up recommendations for the use of Dublin Core in the CIMI Dublin Core Testbed project.
In addition to metadata standards, such as the examples mentioned above, Adlib supports a raft of technical standards, the most common of which is OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting). This protocol is frequently used by aggregators for harvesting metadata and transmitting them to Europeana. The protocol can be used in combination with various metadata standards, such as Dublin Core. Another commonly used protocol is SRU (Search/Retrieval via URL). SRU is widely used in library environments to duplicate bibliographic data from external sources. The metadata standard that is commonly used in combination with SRU is MARC-XML (MARC21).
As the famous computer scientist Andrew S Tanenbaum lamented in Computer Networks, 2nd ed., p. 254: “The nice thing about standards is that you have so many to choose from.”
As far as standards are concerned, your investment in Adlib software has definitely been a wise investment. Because of its compatibility with so many standards, Adlib is a truly open system.
