An identifier is a name that identifies (that is, labels the identity of) either a unique object or a unique class of objects, where the "object" or class may be an idea, physical [countable] object (or class thereof), or physical [noncountable] substance (or class thereof). The abbreviation ID often refers to identity, identification (the process of identifying), or an identifier (that is, an instance of identification). An identifier may be a word, number, letter, symbol, or any combination of those.
The words, numbers, letters, or symbols may follow an encoding system (wherein letters, digits, words, or symbols stand for (represent) ideas or longer names) or they may simply be arbitrary. When an identifier follows an encoding system, it is often referred to as a code or ID code. For instance the ISO/IEC 11179 metadata registry standard defines a code as system of valid symbols that substitute for longer values in contrast to identifiers without symbolic meaning. Identifiers that do not follow any encoding scheme are often said to be arbitrary IDs; they are arbitrarily assigned and have no greater meaning. (Sometimes identifiers are called "codes" even when they are actually arbitrary, whether because the speaker believes that they have deeper meaning or simply because they are speaking casually and imprecisely.)
The unique identifier (UID) is an identifier that refers to only one instance--only one particular object in the universe. A part number is an identifier, but it is not a unique identifier--for that, a serial number is needed, to identify each instance of the part design. Thus the identifier "Model T" identifies the class (model) of automobiles that Ford's Model T comprises; whereas the unique identifier "Model T Serial Number 159,862" identifies one specific member of that class--that is, one particular Model T car, owned by one specific person.
The concepts of name and identifier are denotatively equal, and the terms are thus denotatively synonymous; but they are not always connotatively synonymous, because code names and ID numbers are often connotatively distinguished from names in the sense of traditional natural language naming. For example, both "Jamie Zawinski" and "Netscape employee number 20" are identifiers for the same specific human being; but normal English-language connotation may consider "Jamie Zawinski" a "name" and not an "identifier", whereas it considers "Netscape employee number 20" an "identifier" but not a "name". This is an emic indistinction rather than an etic one.
In metadata, an identifier is a language-independent label, sign or token that uniquely identifies an object within an identification scheme. The suffix identifier is also used as a representation term when naming a data element.
ID codes may inherently carry metadata along with them. For example, when you know that the food package in front of you has the identifier "2011-09-25T15:42Z-MFR5-P02-243-45", you not only have that data, you also have the metadata that tells you that it was packaged on September 25, 2011, at 3:42pm UTC, manufactured by Licensed Vendor Number 5, at the Peoria, IL, USA plant, in Building 2, and was the 243rd package off the line in that shift, and was inspected by Inspector Number 45.
Arbitrary identifiers might lack metadata. For example, if a food package just says 100054678214, its ID may not tell anything except identity--no date, manufacturer name, production sequence rank, or inspector number. In some cases, arbitrary identifiers such as sequential serial numbers leak information (i.e. the German tank problem). Opaque identifiers--identifiers designed to avoid leaking even that small amount of information--include "really opaque pointers" and Version 4 UUIDs.
In computer science, identifiers (IDs) are lexical tokens that name entities. Identifiers are used extensively in virtually all information processing systems. Identifying entities makes it possible to refer to them, which is essential for any kind of symbolic processing.
In computer languages, identifiers are tokens (also called symbols) which name language entities. Some of the kinds of entities an identifier might denote include variables, types, labels, subroutines, and packages.
Which character sequences constitute identifiers depends on the lexical grammar of the language. A common rule is alphanumeric sequences, with underscore also allowed, and with the condition that it not begin with a digit (to simplify lexing by avoiding confusing with integer literals) - so
foo, foo1, foo_bar, _foo are allowed, but
1foo is not - this is the definition used in earlier versions of C and C++, Python 2, and many other languages. Later versions of these languages, along with many other modern languages support almost all Unicode characters in an identifier. However, a common restriction is not to permit whitespace characters and language operators; this simplifies tokenization by making it free-form and context-free. For example, forbidding
+ in identifiers due to its use as a binary operation means that
a + b can be tokenized the same, while if it were allowed,
a+b would be an identifier, not an addition. Whitespace in identifier is particularly problematic, as if spaces are allowed in identifiers, then a clause such as
if rainy day then 1 is legal, with
rainy day as an identifier, but tokenizing this requires the phrasal context of being in the condition of an if clause. Some languages do allow spaces in identifiers, however, such as ALGOL 68 and some ALGOL variants - for example, the following is a valid statement:
real half pi; which could be entered as
.real. half pi; (keywords are represented in boldface, concretely via stropping). In ALGOL this was possible because keywords are syntactically differentiated, so there is no risk of collision or ambiguity, spaces are eliminated during the line reconstruction phase, and the source was processed via scannerless parsing, so lexing could be context-sensitive.
In most languages, some character sequences have the lexical form of an identifier but are known as keywords - for example,
if is frequently a keyword for an if clause, but lexically is of the same form as
foo namely a sequence of letters. This overlap can be handled in various ways: these may be forbidden from being identifiers - which simplifies tokenization and parsing - in which case they are reserved words; they may both be allowed but distinguished in other ways, such as via stropping; or keyword sequences may be allowed as identifiers and which sense is determined from context, which requires a context-sensitive lexer. Non-keywords may also be reserved words (forbidden as identifiers), particularly for forward compatibility, in case a word may become a keyword in future. In a few languages, e.g., PL/1, the distinction is not clear.
The scope, or accessibility within a program of an identifier can be either local or global. A global identifier is declared outside of functions and is available throughout the program. A local identifier is declared within a specific function and only available within that function.
For implementations of programming languages that are using a compiler, identifiers are often only compile time entities. That is, at runtime the compiled program contains references to memory addresses and offsets rather than the textual identifier tokens (these memory addresses, or offsets, having been assigned by the compiler to each identifier).
In languages that support reflection, such as interactive evaluation of source code (using an interpreter or an incremental compiler), identifiers are also runtime entities, sometimes even as first-class objects that can be freely manipulated and evaluated. In Lisp, these are called symbols.
Compilers and interpreters do not usually assign any semantic meaning to an identifier based on the actual character sequence used. However, there are exceptions.
In some languages such as Go, identifiers uniqueness is based on their spelling and their visibility.
Many resources may carry multiple identifiers. Typical examples are:
The inverse is also possible, where multiple resources are represented with the same identifier (discussed below).
Many codes and nomenclatural systems originate within a small namespace. Over the years, some of them bleed into larger namespaces (as people interact in ways they formerly hadn't, e.g., cross-border trade, scientific collaboration, military alliance, and general cultural interconnection or assimilation). When such dissemination happens, the limitations of the original naming convention, which had formerly been latent and moot, become painfully apparent, often necessitating retronymy, synonymity, translation/transcoding, and so on. Such limitations generally accompany the shift away from the original context to the broader one. Typically the system shows implicit context (context was formerly assumed, and narrow), lack of capacity (e.g., low number of possible IDs, reflecting the outmoded narrow context), lack of extensibility (no features defined and reserved against future needs), and lack of specificity and disambiguating capability (related to the context shift, where longstanding uniqueness encounters novel nonuniqueness). Within computer science, this problem is called naming collision. The story of the origination and expansion of the CODEN system provides a good case example in a recent-decades, technical-nomenclature context. The capitalization variations seen with specific designators reveals an instance of this problem occurring in natural languages, where the proper noun/common noun distinction (and its complications) must be dealt with. A universe in which every object had a UID would not need any namespaces, which is to say that it would constitute one gigantic namespace; but human minds could never keep track of, or semantically interrelate, so many UIDs.
|atomic number, corresponding one-to-one with element name||international (via ISV)|
|Australian Business Number||Australian|
|CAGE code||U.S. and NATO|
|CAS registry number||originated in U.S.; today international (via ISV)|
|CODEN||originated in U.S.; today international|
|Digital object identifier (DOI, doi)||Handle System Namespace, international scope|
|DIN standard number||originated in Germany; today international|
|E number||originated in E.U.; may be seen internationally|
|Employer Identification Number (EIN)||U.S.|
|Electronic Identifier Serial Publicaction (EISP)||international|
|Global Trade Item Number||international|
|Group identifier||many scopes, e.g., specific computer systems|
|International Chemical Identifier||international|
|International Standard Book Number (ISBN)||ISBN is part of the EAN Namespace; international scope|
|International eBook Identifier Number (IEIN)||international|
|International Standard Serial Number (ISSN)||international|
|ISO standard number, e.g., ISO 8601||international|
|Library of Congress Control Number||U.S., with some international bibliographic usefulness|
|Personal identification number||many scopes, e.g., banks, governments|
|Personal identification number (Denmark)||Denmark|
|Pharmaceutical code||Many different systems|
|Product batch number|
|Serial Item and Contribution Identifier||U.S., with some international bibliographic usefulness|
|Serial number||many scopes, e.g., company-specific, government-specific|
|Service batch number|
|Social Security Number||U.S.|
|Tax file number||Australian|
|Unique Article Identifier (UAI)||international|
Manage research, learning and skills at defaultlogic.com. Create an account using LinkedIn to manage and organize your omni-channel knowledge. defaultlogic.com is like a shopping cart for information -- helping you to save, discuss and share.