The third type of data is normalized heading data or normalized human-readable identifiers. Normalized heading data is designed to be able to stand on its own in a display (or index) of many other normalized headings matched on a search, quickly and concisely identifying the entity it represents to as many users as possible, including both users familiar with and users unfamiliar with the entity being identified. "Stands on its own" means that the heading can identify the entity without the context of the entire work or expression description. (See Principle 1 above.)
There are four main functions for normalized heading data. First, the work and expression being described are given a normalized heading or human-readable identifier which identifies the work and expression to users; this used to be called the main entry. Secondly, normalized heading identifiers for works related in some way to the work being described are used to link the user back and forth between the work being described and the related work; these used to be called related work added entries. Thirdly, normalized heading identifiers are used to link back and forth between entities to which this work is related by virtue of membership in entity categories such as the works of a particular author, or works on a particular subject, or some other shared characteristic relationship; these used to be called author added entries, subject added entries, genre/form added entries, classification numbers, etc. Finally, variant normalized heading identifiers for all of these entities (works, expressions, creators, subjects, genre/forms, disciplines) are collected to enable the user to search under any variant for an entity and find the entity desired; these used to be called either title added entries (on bibliographic records) or cross references (on authority records).
There are four reasons why it is useful to create name-title human-readable work identifiers when applicable: 1) the name-title work identifier does double duty by collocating (i.e., bringing together in a display) not just the expressions of a work, but also the works of a creator; 2) the name-title work identifier collocates works on a subject or in a genre-form under creator name enabling catalog users to identify creators who have created extensively in a particular genre or written extensively on a particular subject; 3) the name-title work identifier allows linkage of the name part of the identifier to a record or other collection of data that represents that creator entity, thereby clustering all variant names for that particular entity; 4) this practice of creating name-title work identifiers conforms to the work identification practice implemented in millions of existing MARC 21 bibliographic and authority records. Name-title work identifiers constitute a continuum between our legacy cataloging data and the cataloging data of tomorrow.
Catalog use studies consistently show that the majority of catalog users look for known works and that they tend to know these works by their authors (creators) and titles in conjunction. Therefore, the name-title work identifier is so important in the building of effective catalogs that, even if systems can't solve the problem of linking the creator part of the identifier to the creator authority record to enable global updating (and most current global updating software can't do this anyway), the RDF data model behind these rules suggests that the creator name be used in conjunction with the title to identify the work, rather than kept separate so as to link up with the person entity. If computer software cannot be designed to be smart enough to provide maintenance when the creator name changes, human editing may be necessary.
In the RDF world, normalized data will correspond to entities that also have URI's. The entities could be referenced by means of the URI's (in RDF terms, datatype=non-literal), and the human-readable identifiers could reside in the location referenced by the URI, to be assembled on demand for display to catalog users. (It remains to be seen whether the internet can provide the speed necessary to make display assembly invisible to users! This approach was largely rejected in the mainframe and client-server environments because the necessary computer power was not yet available.)
Ideally, entities will have human-readable identifiers available in all languages, scripts and transliterations, and it will be possible to switch on demand to a preferred identifier in the users' preferred language, script and/or transliteration scheme.
Note that normalized human-readable identifiers or headings need to be designed not only to stand on their own without context in a heading display, as noted above, but also to sort effectively, so as to facilitate efficient scanning when a user’s search has matched hundreds of different entities. They also need to be designed to enable linking for the demonstration of relationships. In some ways, a normalized human-readable identifier should be conceived of as the name of a relationship or the explanation for a link; it should make it clear to a user what exactly is going to happen if they click on a particular hotlink.