A user who contributes a resource (e.g., a software package or a document) by making it available via our virtual software repository is said to have published the resource. Two types of location-independent names may be assigned by the publisher to the resource. For a resource that is made available as a file or a set of files, a Location Independent File Name (LIFN) may be assigned. A LIFN refers to the particular sequence of bytes making up that file, or in the case of a set of files, to the set of LIFNs for those files. Once a LIFN has been assigned to a particular sequence of bytes, that binding may not be changed. Various ways of enforcing this requirement are discussed in Section 4.
The other possible type of name is the Uniform Resource Name (URN), which is a long-lasting name that may be used by humans to refer to some network-accessible resource, be it a Web page or a telnet interface. The exact contents of the resource named by a URN can change. For example, accessing a URN for ``the current version of LAPACK'' would give a different result following a new release of the LAPACK package.
The LIFN and URN name spaces are subdivided among several publishers, also called naming authorities, who are responsible for ensuring the uniqueness of names assigned within their portions of the name spaces.
A name is formed by concatenating the registered naming authority identifier and the unique string assigned by the naming authority. For the Netlib naming authority, whose identifier is netlib, the unique string for a LIFN consists of the MD5 fingerprint [5] of the file. This fingerprint is a 128-bit quantity resulting from applying the MD5 function to the contents of the file. The function is designed to make it computationally infeasible to find a different sequence of bytes that produces the same fingerprint. The unique string used for a URN is the unique name by which the resource is known in the Netlib Repository - for example, lapack for the current version of the LAPACK package. The LIFN and URN are formatted as
LIFN:<publisher id>:string URN:<publisher id>:string
The publisher may provide a description for each name it assigns. The description may include information such as title, author, abstract, etc. Suggested attributes for software resources include programming language and system requirements, and for mathematical software, the GAMS classification [1]. A description may also include a supersedes field if the file supersedes a previous one (e.g., a new version of a software package). The description for a LIFN should include an MD5 or similar fingerprint, if that fingerprint is not part of the LIFN itself. To enable authentication, the entire description may be cryptographically signed, as discussed in Section 4. Portions of the description may be exported to resource discovery servers, which provide search services based on resource descriptions. A search service may also accept value-added descriptions submitted by users other than the publisher (e.g., critical reviews). Multiple descriptions may be combined into a union record, while preserving the source of each description, as in [3]. The URN or LIFN exported to the search service provides a unique long-lived key, so that descriptions may be unambiguously associated with a resource, and so that a resource turns up at most once in a list of search hits.
For a name to be useful, there must be some means of resolving a name to a location from which the resource can be retrieved or accessed. Thus, the publisher, as well as any other parties that mirror the resource, must register such location with the appropriate name-to-location lookup services. Such name-to-location services are discussed in Section 3.
Thus, publishing a resource involves the following steps: