Web Proper Names: Naming Referents on the Web

Harry Halpin
Institute for Communicating and Collaborative Systems
School of Informatics
University of Edinburgh
2 Buccleuch Place
Edinburgh, United Kingdom
Henry S. Thompson
Human Communications Research Centre
School of Informatics
University of Edinburgh
World Wide Consortium
2 Buccleuch Place
Edinburgh, United Kingdom


When http: URIs are used to refer to things as opposed to web pages, ambiguity arises on the Web. Both humans and machines need to solve the question of what some person is actually referring to when they use a http: URI, especially if that URI can be used both to refer to a web page and a thing that is not on the Web. We clarify the problem of reference on the Web. We then propose a solution based on the ability of humans to verify the results of a search engine request. We call our solution called "Web Proper Names" and show that it provides a distributed approach to creating and sharing Web names for things, allows use of Web names as for non-Web things to be easily distinguished from the use of URIs to address web pages and that achieves interoperability of names. We show how this approach is used to create canonical HTML RDDL file for things, and show how the technique can be used as an improved XML-based bookmark exchange language and as an "bottom-up" approach to the Semantic Web.


The Web is about things

The value of the World Wide Web stems in large part from the fact that the varied constituents of the Web are about things--they describe things or picture things or discuss things. Often, although not always, these things are not themselves on the Web, rather they exist in the physical world. The ability to understand something as being about something, as being oriented towards something else without any direct connection to it, is crucial to human intelligence. Any effort to make the Web more intelligent, for example by automating the exploitation of resources on the Web, will have to somehow reproduce the human ability to understand what things are about.

This is an issue of immense practical importance: when someone searches the Web, they are looking for information about something. At present no widespread automatic processes exist to index, organize, share, or even decide what web pages are about--all searches have to work with is text. The effort to provide machine-readable metadata through standards such as RDF and description logics as embodied in OWL are efforts to improve this situation. Although such efforts do allow a human to express what they believe a web page is about in a standard way, they still beg the question of how to interoperably identify real-world things in such metadata.

Unfortunately, no-one from expert logicians to philosophers of consciousness have a solid idea about how we determine whether or not a thing is actually about something else. On the surface this aboutness seems physically spooky: I can think about the Eiffel Tower in Paris without being in Paris, or even having ever set foot in France. I can imagine what the Eiffel Tower would look like if it was painted blue. I can even think of a situation where the Eiffel Tower wasn't called the Eiffel Tower. Most importantly for our purposes, I can view a web page, either by typing a URL such as http://www.tour-eiffel.fr/ into a browser or by typing Eiffel into a search engine and following one of the links it provides. Having done this, I know at a glance if the page is actually about the Eiffel Tower, or a hotel near the Eiffel Tower, as opposed to the object-oriented programming language Eiffel, or the film The Lavender Hill Mob, and so on. Yet this knowledge depends on fundamental aspects of human intelligence such as language understanding, scene recognition and so forth, which have proved distressingly resistant to automation.

Names for things

As presently constituted, the effort to automatically exploit the content of the Web is a broad movement, ranging from information retrieval performed by term-based search engines to the Semantic Web and Topic Map standardization efforts. Some of these approaches use URIs as the primary terms in the languages they use to express metadata, that is, information intended for machine processing. Metadata is composed of logical sentences which in turn use URIs to stand for things, for example:


All the metadata sentences we use for examples in this paper have this form, that is, three URIs, to be understood as subject, predicate, object. The predicate dc:creator resolves to http://www.purl.org/dc/elements/1.1/, which defines its meaning as "an entity primarily responsible for making the content of the resource." Since a resource can be anything, it is unclear if the `resource' in this case is the Eiffel Tower or the web page about the Eiffel Tower, or what "making" means. On one reading, the first URI of this triple stands for the Eiffel Tower, the third URI stands for Gustave Eiffel, its architect. One could imagine an alternate reading in which one could think this statement said Gustave Eiffel created a web page called http://www.tour-eiffel.fr.

This ambiguity about whether a URI refers to a web page or something else is everywhere. While this may be easy enough for a human to figure out using context (such as their historical knowledge of the Eiffel Tower), there is no obvious way for a machine to determine whether a URI stands for a web page or for a thing. One way is to partition URIs into only those about things and those only about web pages, yet there is no mechanism for distinguishing between the two. This problem has been brought up before by the Semantic Web and Topic Map communities, as RDF predicates such as foaf:page in the Friend-of-a-Friend vocabulary (http://www.foaf-project.org) and the subject indicator parameter of Topic Maps show. However, most solutions only solve the problem in small domains via appeal to human-readable documentation. Providing one well-specified RDF vocabulary for things as opposed to web pages does not solve the problem in general. RDF vocabularies created for this problem in general (such as a theoretical DocumentIsAboutThisThing) only cope with the issue by mapping the object of the predicate to an inverse functional property of the thing (which are quite rare for most things), another potentially ambiguous http: URI, or a literal that is also likely to be ambiguous. In the terms of philosophy, all these approaches fall victim to the regress of the Symbol Grounding Problem[6].

If the same thing is given multiple URIs by differing authors, in the absence of any agreed central authority which decides what URIs should be used to stand for what things, there is a real risk that the Semantic Web will consist of a vast number of self-consistent but mutually incommensurable collections of metadata. Speaking informally, the URIs in the above example just address web pages. When a software agent fetches a web page from a URI, it's the web page addressed by the URI, as rendered by the agent on the basis of the encoding (such as HTML) returned by a server, that is actually about the Eiffel Tower or Gustave Eiffel. We'll come back to this distinction below.

The first challenge for the project of automating the exploitation of the Web is thus not to know what web pages are about--that's too hard for the time being. Just separating URIs for things from URIs for web pages and knowing when two pages are about the same thing would be a huge step forward. Other researchers[5] are also trying to address this problem in the context of the Semantic Web.

We believe the Web needs a solution to this problem which

  1. Provides a distributed approach to creating and sharing Web names for things;
  2. Allows use of Web names for things to be easily distinguished from the use of URIs to address web pages;
  3. Allows for efficient and reliable determination of whether distinct Web names are names for the same thing;
  4. Does not require a single canonical name, while still achieving interoperability of names.

Our solution to this problem exploits the pervasive availability of search engines with substantial coverage by using them to find sets of pages that human users judge to describe certain things. In an loose analogy with natural language, where phrases such as the Eiffel Tower are called proper names, so we call our approach Web Proper Names, and use wpn: in our examples as a candidate URI scheme for Web Proper Names. Although the concept can be refined further, a Web Proper Name (WPN) for something is usually composed of a set of search terms known to return primarily URIs of web pages which describe that thing. It's at least initially plausible that such an approach to naming things for the Web should satisfy the requirements listed above--the rest of this paper is devoted to spelling out the details and demonstrating that in fact this is the case.

Note that we do not require that it be possible given a web page to automatically determine the Web Proper Name of whatever it describes. This would set the bar too high--even names in the real world don't have this property.

Philosophical Underpinnings


Although terminology in this field often is confused, the underlying phenomena are reasonably clear: Generally, when something is understood to be about something else we talk about reference, and the thing referred to is called the referent. Whenever the word thing is used we mean a thing that is not by nature on the Web, such as the Eiffel Tower as opposed to a web page about it. The reference relation is considered semantic, a relation involving meaning. One kind of reference is that which starts from names--a class of linguistic expressions that are about something else. Proper names are names that refer uniquely to one referent, at least in an ideal situation. Figure 1 illustrates an example of this relationship.

Figure 1: The reference relation
\begin{figure}\centering \epsfig{file=refer.epsi} \end{figure}

On the Web this relationship becomes more complex. The draft recommendations of the W3C's Technical Architecture Group[7] say that a URI identifies a resource, and that browsers can retrieve representations which represent that resource.

Since the status of the term resource is still under development by the Web community, we will not use it in this paper. As it stands a resource can be anything, including both things and web pages. The URIs by which resources are identified do not seem to be connected to them in the way that names are to their referents (see §2.4 below). Henry S. Thompson refers to an actual person, while the URI of his web page may be intended to refer to him as a rigid designator or alternatively just to his web page.

Our take on the ordinary understanding of URIs is that a URI addresses a Web-based encoding of a description or depiction of a denotation. An encoding is the character sequence that is actually retrieved, along with a specification of its media type, e.g. HTML or SVG. Informally it is the source for a web page, although the term is intended to be broad enough to cover non-web standards that encode their data more directly, such as JPG for images or MP3 for sound.

A linguistic description or pictorial depiction is the rendered output of a program given an encoding. Henceforth we will use expression as a cover term for the whole range of humanly-perceivable forms whose standardized encoding is addressed and retrievable by URIs--in other words expression is a cover term for HTML pages, SVG and JPG images, MP3 audio streams, and so on as presented to humans by software. Also web pages will be used informally to cover both encodings and expressions in one term, and so will both cover the everyday language use of the term (as for HTML pages) but also refer to a wider set of phenomena (such as a URI addressing an audio stream). Following Goodman[4], we use denotation for that which is depicted or described by an expression, where the philosophical treatment of reference would use referent.

Subject to connectivity, the encoding addressed by a URI can be fetched, rendered as an expression by a software agent and seen or heard by a human, who can then determine what if anything the expression denotes. Figure 2 illustrates this. To summarize: the URI http://www.tour-eiffel.fr addresses an encoding in HTML, which can be retrieved by a web-browser, which renders the encoding as an expression composed of text and pictures, and these text and pictures will be recognized by a human being as denoting the actual Eiffel Tower in Paris

Figure 2: Description and denotation on the Web
\begin{figure}\centering \epsfig{file=web_refer.epsi} \end{figure}

We can now be more precise about what's going on with respect to Web searches. When searching, a user typically wants to fetch expressions constituting descriptions (such as HTML or XML pages) or depictions (such as JPG or SVG images) that actually describe or depict some denotation they are interested in. When searching the Web, many expressions can be found which are not about the item of interest, and distinguishing those that denote the item of interest from those that do not is not straightforward. The human ability to do this, as remarked above, is evidently based on a wide range of linguistic and cognitive abilities, which machines have so far proved unable to reproduce.

In so far as determining the denotation of a web page may take us beyond the Web and into the rest of the real world, it is evidently beyond the reach of automation. What we can imagine being within reach is the slightly different problem of determining whether two expressions have the same denotation, in which case we say they are equivalent in terms of "real world" meaning or semantics. That determination is not in principle out of reach of automation if the denotations of the two expressions have been explicitly named, and it is the goal of the WPN effort described here to achieve this by providing a Web-appropriate naming mechanism.

The Use-Mention Distinction

A note of caution, in the guise of introducing one more bit of terminology. The connection from URI to expression and from expression to denotation encourages a confusion which is analogous to the use-mention confusion familiar to philosophers of language. Consider the difference between "Rice is tasty" and "rice is a one-syllable word." The first sentence uses the word rice to refer to a foodstuff in the world. The second sentence mentions the word rice in order to discuss a property of the word itself. There is an analogous problem on the Web when a URI occurs in metadata. In practice we observe that such metadata may either be understood as saying something about the expression whose encoding is addressed by the URI (a mention), or as saying something about the denotation of said expression (a use). For example, in order to understand the following as saying that Henry Thompson's W3C home page was created by Henry Thompson, we have to interpret the first URI as a mention but the second as a use:

http://www.ltg.ed.ac.uk/~ ht/

For a range of reasons, which we will return to below, we think it's a mistake in metadata to use URIs in general for things--most URIs should be understood as being mentioned in metadata, that is, as being used to refer to the web pages they address.

To refer to things in the world in metadata, we offer Web Proper Names as a particular kind of URI (that is, a URI using a particular URI scheme) intended for this purpose. This makes the understanding of URIs in metadata the opposite of the understanding of words in ordinary sentences. In ordinary sentences, words that are being used as names for things are unmarked, while words that are being mentioned as not being strictly names for things are usually marked, either by quotes, italics, or boldfaced as in our previous example using rice. Whereas the unmarked case for words is use and the marked case is mention, we are proposing that the unmarked case for URIs should be analogous to mention and the marked case (marked by the wpn: URI scheme for example, or retrieving a particular RDDL format) should be analogous to use.

Search engines and descriptions

Although the philosophical story and the Web story (see Figure 1 and Figure 2 above respectively) appear to be different, in that in the one case reference is unmediated, but in the other mediated by a web page, in fact the parallel is much stronger.

The classic approach of Frege posits three elements to any reference: the name, the sense, and the referent[3]. The actual thing in the world is still the referent, and a name is a symbol that has a referent. The sense is the mode of presentation, a type of public, objective knowledge about the item. Frege himself would likely judge this to be Platonic in nature. Russell and others analyzed proper names as "abbreviated" descriptions. Their descriptivist theory of names analyzes a name as identifying a set definite descriptive terms [12]. These descriptive terms could be logical or linguistic in form. On the descriptivist account a name maps in the head of its user to a private concept of what the referent is. Sense is the public projection of that private concept among a shared community. The third party of sense mediates the reference relationship. In Frege's classical example, Hesperus has a sense ("the morning star") different from that of Phosphorus ("the evening star"), yet both have the same referent, the planet Venus.

The descriptivist notion of sense is parallel to the place of search terms in the Web story. A web page addressed by a URI can thereby be fetched and shared among the community of Web users. The notion of a sense as composed of definite descriptive terms also has an intriguing connection to the contemporary use of search engines. Typing descriptive terms such as Eiffel, Tower and Paris into a search engine returns URIs that address descriptions of the actual Eiffel Tower. In the context of the Web, there is usually a non-arbitrary, although not strictly necessary, relationship between the descriptive terms and whatever the recovered web pages denote. Insofar as we've hinted that a Web Proper Name is a collection of search terms, this analogy is encouraging, particularly because the first step, from search terms to URIs, is automated and distributed.

It is important to note, however, that there are problems treating sense as a set of descriptive terms. It is in practice very difficult to come up with a set of descriptions that identifies exactly one referent. The Eiffel Tower is "a large metal monument." To distinguish it from the multitude of other large metal monuments in the world, the Eiffel Tower is "a large metal monument in Paris." There are other large metal monuments in Paris, and the Eiffel Tower would still be the Eiffel Tower if it were moved to Lake Havasu City. Searle addresses this issue in his cluster theory of names[13], in which he suggests that only some or most of the terms intended to identify a referent need do so. Furthermore, many of the descriptive terms, or indeed all of them, may also describe things which are not the intended referent.

Analogously, when using a search engine such as Google, typing in search terms for the Eiffel Tower such as Eiffel Tower Paris results in some web pages about the actual Eiffel Tower in Paris, but not all of them, and also web pages of things only marginally connected to the Eiffel Tower, such as hotels with views of the Eiffel Tower, or worse, something as inappropriate as an Eiffel programming language conference in Paris. The size of the retrieved set will also be quite large ("about 379,000" according to Google on the day of writing).

This suggests a refinement not usually found in philosophical accounts: the use of negative search terms. For example, the fact that the Eiffel Tower is not a hotel can be reflected by using Eiffel Tower Paris -hotel as the set of search terms. This has a dramatic effect--at the time of writing the size of the set Google returns for these terms is "about 166,000".

The analogy we are developing looks like this--a Web Proper Name should function like a natural language name, identifying a referent. It consists of a set of search terms, including negative ones. Courtesy of a search engine, it determines a set of URIs that address web pages. At least a subset of those in turn denote the referent of interest.

When someone uses a search engine, if the majority of the descriptions retrieved for a given set of search terms, particular the high-ranking ones, do in fact describe the desired referent, then the search is generally considered successful. Analogously, a set of search terms is a good candidate for a Web Proper Name if the majority of the URIs retrieved for those terms, particular the high-ranking ones, do in fact address web pages with the same denotation, the intended referent of the Web Proper Name.

Names and descriptions

It's important not to confuse a name with descriptions of its referent. In the real world, we use the name Eiffel Tower to uniquely determine the Eiffel Tower referent. We use names, not descriptions, to identify people. For example, the name Tim Berners-Lee identifies a certain man in Boston who is the Director of the W3C and wrote the book called Weaving the Web about his part in the creation of the World Wide Web. Moreover, when we want to refer to Tim Berners-Lee, we don't have to redescribe him using his title or the book he's written. A name alone determines its referent, at least where all parties involved attach the name to the same referent. Furthermore, this is achieved without appeal to descriptions.

In Naming and Necessity, Kripke says that names function to fix a referent without being a shorthand for sets of descriptive terms[9]. This is in tension with both the descriptivist and cluster theories of names discussed above. Descriptions aren't entirely out of the picture on Kripke's account--they are necessary for disambiguation when the context of use allows more than one interpretation of a name, and they may figure in the process by which things actually get their names.

In Kripke's account an agent or agents fix a name to a referent by a process called baptism, in which a thing and a word are directly associated. Afterwards one can use a name by virtue of being in a causal chain with the baptism. If the agent, the thing being named, and the listener are all co-present, the thing being named can be directly identified, otherwise careful use of descriptive terms will be required in order to adequately identify the object.

Sometimes proper names include ordinary words which themselves contribute to our understanding, for example Prime Minister, Crystal Palace, Big Island. The use of search terms in Web Proper Names parallels this to some extent. Using these terms a search engine can select from the vast number of web pages available on the Web a set which may describe the referent one is interested in. Note that other forms of information such as Semantic Web metadata, or the use of more sophisticated heuristics from information retrieval, may contribute to the selection of this set.

The lessons here for naming on the Web are that names and search terms are not the same, but that search terms can be used to create names for the Web, via web pages, in a productive and interoperable way. Baptism on the Web can be achieved by an appeal to a set of search terms and a search engine which can recover appropriate expressions, which in turn denote the intended referent. The baptizing agent of a Web Proper Name is the owner of the Web Proper Name. The referent is whatever thing the owner is interested in. A Web Proper Name is composed of search terms that given to a search engine will recover a set of URIs which address expressions which can in turn be verified by the baptizing agent as denoting the referent. We can effectively merge our two earlier pictures, as shown in Figure 3.

Figure 3: Web Proper Names
\begin{figure}\centering \epsfig{file=wpn_refer.epsi} \end{figure}

It would be difficult if not impossible to select a set of search terms that uniquely determine a referent, that is, terms which recover a set of URIs such that all the web pages addressed thereby denote the intended referent. That's why the role of the baptizing agent is crucial: It's their job to determine whether the denotation of each web page is really the intended referent. Bar the creation of genuine artificial intelligence, currently only human inspection can check whether or not a given web page denotes a particular referent. A human agent with a referent to baptize must refine a set of search terms until an appropriate subset of the expressions addressed by the URIs recovered by a search engine from those terms denote that referent. They can then promulgate a Web Proper Name.

Details of just what appropriate means above, what a Web Proper Name looks like in detail and how it removes the baptizing agent from ongoing uses, will be given in the next section. Web Proper Names are just a formalization of what many users of the Web do everyday--using a search engine to find web pages about something, getting a list of URIs back and manually checking the descriptions they address to see if they are really about the referent, then changing the search terms if required to improve the result. Web Proper Names allows the results to be packaged via a URI scheme (as detailed in §3) or a file (as detailed in §4), and so shared and used as the foundation for further information gathering on the Web.

Web Proper Names Specification

A Web Proper Name is a Web-usable name for a referent, based on a set of search terms which recover a set of web pages that denote that referent. A Web Proper Name not only may determine many web pages, but a single web page may participate in many Web Proper Names. A Web Proper Name should not be confused either with the set of search terms, the referent itself, the set of descriptions, or the additional information needed to situate the context of its baptism. All the parameters below are optional, because in certain circumstances all that is wanted is the use/mention distinction, although the more parameters are specified the greater the potential value of the WPN. WPNs are not limited to naming things that already have ordinary proper names, such as the Eiffel Tower or Tim Berners-Lee, but can be constructed to name virtually anything, such as my eldest sister-in-law and lambda calculus, as well as fictional referents such as unicorns. Note that since there are no restrictions on the referent, we allow what someone might consider to be multiple referents to be taken as the singular referent of a Web Proper Name.

The creation of a Web Proper Name via a search engine can be described concisely in terms of information retrieval. Assume a collection of web pages, T, which is the total number of web pages on the Web. There is an agent, assumed to be human in this paper, that has an information need about referent n that we are unable to directly access. They express this as a request to a search engine in terms of a linguistic object, the search terms, that the search engine transforms into a query (the engine may stem input words to obtain terms, add system-derived weights to terms, and so on) over its document index descriptions. A search retrieves some subset R of T, which we call the result sequence. We call it a "sequence" as opposed to a "set" since it is ordered. The agent inspects and assesses some set of web pages C that is a subset of R and we call C the checked sequence. Each web page in C is determined to either be or not be about referent n by the agent, partitioning C into two sequences, the correct checked sequence CC whose members are about referent n and the incorrect checked sequence CI whose members are not about n, which are equivalent to relevant and not relevant web pages respectively in the terminology of information retrieval.

Since what a web page is about is on some level inaccessible and may vary over agents, only inspection of the content will suffice to characterize the web page as relevant or not. We allow multiple copies of the same content to be in the correct checked sequence(CC), although we do require unique URIs. Notice that there can be relevant web pages in the whole Web(T) that are not in the result sequence(R) and relevant web pages in that sequence R that are not in the checked sequence(C), making it impossible to establish a recall value for the checked sequence(C) in terms of the whole Web(T) or the result sequence(R). Also note that we are not measuring performance of a search engine. While there might be other useful pages about n, we want only a sufficient, not necessary, set of web pages to characterize referent n for the agent. Necessary is far too strong for many referents, for referents usually are not fully characterized by anything on the web. However, a collection of web pages can be good enough to characterize them to the degree deemed needed by the agent. It would be trivial to form a query that just retrieved the correct checked sequence(CC); all it would perhaps require is the pathological concatenation of the text of each member of that sequence. This does not reflect the actual search process used to find the correct checked sequence(CC). To capture the actual search used to find CC, we allow the user to "freeze" the relevance feedback of the search engine at any time. After iterating and improving the initial search to get a R of reasonable size, the agent pursues the inspection process to create CC, while saving relevant information such as the search terms. These search terms may not be optimal, but just good enough.

We define a Web Proper Name as a nine-tuple, as follows, with abbreviations for the components in parentheses:

Owner: Identification of the baptizing authority, in a form usable as an http: URI.
Short name: A short mnemonic for the WPN, in a form allowing it to be combined with the Owner to give a valid http: URI.
Engine (se): The domain name of the search engine used.
Date (dt): The date the search was done, in YYYY-MM-DD form.
Terms: The positive and negative search terms used, combined with plus signs, phrases surrounded by double-quotes, spaces in phrases escaped as %20, negative terms marked with minus signs.
Language (ln): The natural language of the terms--for inclusion in the query if the search engine supports language-filtering.
Result Sequence Size (rs): The binary order of magnitude of the cardinality of the sequence of URIs retrieved by the search engine.
Checked Sequence Size (cs): The binary order of magnitude of the cardinality of the subsequence of the Result Sequence that have been checked to determine whether they describe the referent.
Percent Correct (pc): The percentage of the Checked Sequence found to actually describe the referent.

Note that the Checked Sequence is always a subsequence or sequence of subsequences of the Result Sequence, preserving the search-engine-determined ordering of the Result Sequence. The Checked Sequence can only be constructed by human inspection, by fetching the description addressed by each URI in turn and inspecting it.

For use in metadata, a Web Proper Name must be recognizable as such. Accordingly we package the constituents defined above into a URI using the hypothetical wpn: scheme as follows:
wpn://owner/shortName?terms=terms &
se=engine&dt=date&rs= resultSequenceSize&

Since the size of some of the sequences, particularly the Result Sequence, might be quite large, the size of the sequence is expressed as a binary order of magnitude in integer form. The main advantage of the binary order of magnitude encoding is that it allows a fine-grained grasp of the size of small sequence sizes while a coarse-grained grasp of the size of large sequences. A Web Proper Name with the following composition:

Owner: www.ltg.ed.ac.uk/~ht/WPN
Short name: EiffelTower
Engine: www.google.com
Date: 2004-04-29
Terms: eiffel+tower+paris+-hotel+-webcam
Language: en
Result Sequence Size: 17
Checked Sequence Size: 5
Percent Correct: 84

is expressed in a wpn: URI like this:

wpn://www.ltg.ed.ac.uk/~ ht/WPN/EiffelTower?

Requirements and design choices

Each of the constituents of a Web Proper Name is intended to help achieve one or more of the goals we set out initially. The key to interoperability is a form of reproducibility: the Engine, Terms and Language enable anyone to repeat the original query and examine the Result Sequence. This reproducibility is not perfect due to the dynamic nature of the Web, and will change over time. To help deal with this, the time elapsed since the Date, and the Result Sequence Size, allow a user to judge how far things may have changed since the original query. However, one distinct advantage of WPNs is that they can be easily updated by running the search again and inspecting the changes in the results.

The identity of the Owner provides a concrete basis for judging the reliability of the Web Proper Name as a whole, and Percent Correct gives an estimate of the precision of the search terms with respect to the intended referent.

How do we stand then with respect to the four goals stated in §1.2?

Provides a distributed approach to creating and sharing Web names for things

Anyone can create a Web Proper Name, and the components described above can be either published using the wpn: scheme or in an expanded form described below in §4. The fact that anyone can create a Web Proper Name does not distinguish it from URIs in general. What makes Web Proper Names as defined here independently creatable and sharable for the purpose of naming things on the Web in a way that arbitrary URIs are not is that it is easy for independently created Web Proper Names to be compared. This is discussed further in §3.1.3 below.

Allows use of URIs as names for things to be easily distinguished from mention of URIs, i.e. as addresses for web pages

Web Proper Names evidently satisfy this by definition--the use of the wpn: URI scheme ensures this, and this use is the primary justification for the creation of the wpn: scheme. By definition a WPN always denotes its referent. In current usage, an http: URI may or may not be intended to denote a referent, and this intention is not typically determinable by non-human agents.

Allows for efficient and reliable determination of whether two Web names are about the same thing

The design given here for Web Proper Names satisfies this goal at three levels:

  1. by including the Short Name constituent, which can be used to signal the baptizer's intent;
  2. by including the Terms constituent, which specifies the baptizer's intent much more explicitly;
  3. by allowing for much more detailed information about the Checked Sequence, including a partition of its member URIs into correct and incorrect, to be fetched if using the Expanded WPN (see §4 below).

Like reference in real life, there is no absolute guarantee that two WPNs are about the same thing. However, heuristic solutions will, within reason, be able to find out if WPNs are referring to the same or similar things. Significant overlap between the membership of the correct checked sequence of two WPNs gives a strong presumption of identity of intended referent. For many purposes the percentage by which two Web names share the same URIs in their correct checked sequences can be taken as proportional to the degree of certainty that they are about the same thing. This gives a graded and hence more flexible approach to determination of co-reference as compared to some methods e.g. OWL's sameAs construct.

Does not require a single canonical name, while still achieving interoperability of names

The implicit contrast here is with an approach to naming on the Web that requires or assumes some form of centralization, either of names themselves, or of assertions of equivalence of names. Web Proper Names are interoperable without such centralization, because two Web Proper Names can be compared on the basis of their constituents. This is achieved by appeal to the web-accessible form of the WPN itself, not to a universal central authority.

Creating WPNs without a Search Engine

WPNs do not require search engines, and so the search engine and descriptions parameters are optional. URIs (including XML namespaces and those not indexed by search engines) may be gathered from many places; they can be e-mailed directly, seen on the sides of cars, written in ads in magazines, found by casually poking around some web pages. As long as a group of URIs are about the same referent, they can be added to a WPN. This also allows one to make WPNs whose size is only one. Pat Hayes can have a web page he has made as a rigid designator for himself, http://www.ihmc.us/users/phayes/PatHayes.html. This can be made into a WPN of size one for Pat Hayes. Creating WPNs in this manner has some but not all of the advantages of search-based WPNs, such as the use of search terms to find more web pages about the referent in question. It is recommended that these manually created WPNs be packaged as Expanded WPNs as detailed in §4.

Context Dependence and WPNs

With regards to exactly what can qualify as a referent, WPNs and this proposal are agnostic. A WPN should not be confused with its denotation. It is not the task of WPN to define what a referent is, it is the task of the human who created the WPN. WPNs do not claim to create a universal and centralized ontology as Cyc does[10], but rather aims to enable small-scale distributed and cooperative ontologies. The class of referents is as diverse as the possible interests of humans and world itself[14]. While the WPN specification makes no claim about what a referent is in general, it does imply that the owner decides this in each particular case. The context-dependent nature of WPNs is stored in the required parameters--the date of creation and owner URI--although the general principle of incorporating context permeates the whole design of Web Proper Names. The very judgment about whether or not a particular expression is about a referent is a matter of perspective on the part of the owner of the WPN. If one was searching for information about the Eiffel Tower, would pictures of the Eiffel Tower count? This depends on the decisions of the owner. Yet, we expect that there will be some measure of overlap for popular and concrete referents, and this overlap allows statistical measurements of interoperability to be made.

We expect for there could be some question whether a WPN refers to one referent or another. A WPN about Guy Fawkes will also include web pages about both Guy Fawkes and gunpowder. However, while all web pages about Guy Fawkes may also be about gunpowder on some level, not all web pages about gunpowder are also likely to be about Guy Fawkes. The shortname parameter of WPN will likely also be either "Guy Fawkes" or "gunpowder," and the owner can be contacted if the intent is still unclear. This is not even a problem with WPNs per se, but merely the acknowledgment by the WPN that Guy Fawkes and gunpowder are related historically, and detecting such relations is actually an advantage for the user. Certain items of information will be by nature closely related to other items of information conventionally, historically, scientifically, analytically, or in some other manner.

Expanded Web Proper Names

While Web Proper Names are not universal in the sense that a WPN uniquely identifies its referent over the Web for everyone, its format should be uniform, so WPNs may be exchanged and processed in a uniform manner by everyone. We use the name Expanded Web Proper Name (EWPN) for this packaging and expansion of WPN information. EWPNs are especially made to be packaged and used over the http: URI scheme, and as such may be deployed currently.

For many purposes, such as re-checking a WPN or comparing WPNs, the exact URIs recovered from its search terms are crucial. If two EWPNs have a majority of recovered URIs in common, then there is a strong presumption that they are about the same thing or closely related things. However, this can not be determined unless the actual URIs or their content are available. For fine-grained comparison of WPNs or statistics about WPNs, the exact size of the result and checked sequences are needed. The original specification of WPNs is accordingly modified with the additional information detailed above to make the Expanded Web Proper Name specification.

In an EWPN, the original WPN nine-tuple has the following two parameters changed to be exact cardinality:

Result Sequence Size: The exact cardinality of the sequence of URIs retrieved.

Checked Sequence Size: The exact cardinality of URIs in the Result Sequence that have been checked to be about the referent, even if they were not about the referent.

These three new parameters are added to an EWPN:

Correct Checked Sequence Size: Total number of URIs in the Checked Sequence that has been checked and verified by an agent, such as the owner, to actually be about the referent. This means that they have been verified by some investigation of the expression addressed by the URI (or in the case of non-referring URIs, the URI itself).

Correct Checked Sequence: A list of URIs in the Result Sequence that have been checked and are about the referent. The number of URIs in this list will be equal to the Correct Checked Sequence Size.

Incorrect Checked Sequence: A list of URIs in the Result Sequence that have been checked and are not about the referent. The number of in this list will be equal to the Checked Sequence Size minus the Correct Checked Sequence Size.

Further Information: Any further potentially useful information.

The entries in the two lists of URIs may also include optional relevance, comment, and number parameters. The relevance parameter allows the inspecting agent to rate a URI on an ordinal scale as to how relevant to the WPN they are, as well as an optional comment for any additional potentially relevant information on the URI. Search engines return the URIs in a sequence, and so it is recommended that the order of the URI lists be the same order that the search engine returned. A number parameter is provided for each URI to preserve the order returned by the search engine. A number of zero indicates the URI has been added by manual augmentation. The URIs or the content of the URIs may be stored by the user. Since URIs do change, storing the actual content can be very useful.

The Further Information parameter of an Expanded WPN is for additional metadata about the WPN itself over and above the minimum data normally included in an EWPN. Metadata could give version history, such as how often the WPN is updated. More metadata would be crucial if one were merging WPNs, such as one would want to do when building multilingual WPNs.

The information content of an Expanded WPN can be encoded as an XHTML RDDL file[1], allowing things to be distinguished from web pages at the level of retrieved representation, not just at the URI scheme level. This provides a web page that is guaranteed to be about one thing.

As long as the information required by an EWPN is encoded in some form, the encoding is an EWPN, although the HTML RDDL form is taken as canonical. A few of the more obvious non-canonical encodings (XML, RDF, OWL) are explored as examples of WPN use in §5. A WPN RDDL is available at http://www.webpropernames.org/, along with schemas for other encodings. An Expanded WPN may be stored anywhere. We encourage people to store them so they are addressed by a http: URI formed by adding the shortname to their owner identification. We expect WPNs can be stored in other Web-based formats as well, such as Topic Maps. The strength of WPNs lies in the information they contain, not in a particular format.

Uses of Web Proper Names

A URI Scheme to Distinguish Web Pages from Things

The wpn: URI scheme unambiguously refers to things, not web pages. The following triple asserts that the person Henry S. Thompson created his W3C web page:

wpn://www.ltg.ed.ac.uk/ ht/WPN/HenrySThompson?

Is a new URI scheme really required for Web Proper Names? As stated by the W3C[7], "When a software agent dereferences [a non-http:] URI, if what really happens is that HTTP GET is invoked to retrieve a representation of the resource, then an "http" URI would have sufficed." The primary intended use of Web Proper Names is to identify the referents in metadata sentences, while the primary use of http: URIs is to address a web page or group of web pages. In practice, the "hash" is often added to http: URIs to denote a referent, but this convention is not always followed in practice and is a clear overloading of the use of fragment identifiers. Likewise, a WPN is also useful for its role as a name that is intrinsically (i.e. notationally) distinguishable for normal http: URIs. A similar proposal, the tdb:[11] URI scheme of Larry Masinter is a subset of the wpn: scheme, with wpn: having parameters for interoperability of names.

As Authoritative Web Pages

The information in an Expanded WPN can be stored as a RDDL document that can usefully be displayed in a web browser for human perusal. Currently, while http: URIs are allowed to denote things not on the Web, it is unclear what type of representation should be retrieved for such URIs. Now often no representation is retrieved, which is unfortunate since there are many other URIs with no retrievable representation that do not refer to referents, such as URIs often used to denote XML namespaces. The RDDL form of a Web Proper Name can be used a standard representation for URIs that denote things, eliminating ambiguity and providing useful information for the user. An example screenshot of an EWPN RDDL for the Eiffel Tower is included in 4.

Figure 4: Screen Shot of an Expanded WPN RDDL
 Example of Authoritative Web Page

As Improved Bookmarks

The creation, storing, and collection of EWPNs can be easily integrated into web browsers in the same fashion as bookmarks. There are already several established XML-based bookmark schemes like XBEL (XML Bookmark Exchange Language), yet an EWPN can do more than a conventional bookmark scheme[2]. While a bookmark is shorthand for a single URI, a WPN is a shorthand for a group of URIs about a particular referent. The coincides with the informal practice of Web users to group ordinary bookmarked URI together by subject. An WPN offers a crucial advantage over ordinary bookmarks: a set of search terms. Instead of manually marking a bookmark, a user often will remember a set of search terms. Due to rate of change of the Web, the use of a search engine can often return more up-to-date and informative URIs than a possibly outdated or broken bookmark, returning a cluster of web pages that may contain more information about the subject of interest. Many search engines such as AskJeeves and Yahoo have recently deployed such technology for their users, and many browsers also allow it. A standardized XML format for searches such as EWPN that allows the sharing of search results and terms across both browsers and search engines is needed.

As in bookmarks, when the user finds a search result that is pertinent to their referent, they can add that URI to the correct checked sequence by adding it with a few clicks of a mouse. One possible objection to both the WPN and the Semantic Web efforts is that they force the user to create new metadata. However, the WPN effort enables users to continue to use search engines as they currently do to create WPNs with no new behavior or substantial work required.

The Semantic Web from the Bottom-Up

The WPN proposal is complementary to ontology-based annotation. Already, there is movement to store bookmarks as RDF as exemplified by Annotea's bookmark scheme[8]. A bookmark can be stored as a metadata about in a particular web page, and in a similar manner an EWPN can be stored as RDF; all EWPN formats can be easily transformed into RDF, since the base component of a WPN are URIs. This would allow the expressive power of OWL to be used in the management of EWPNs. For example, unionOf and intersectionOf can then be used automatically merge EWPNs and find difference sets of EWPNs. From the viewpoint of ontology development, this also provides a very attractive methodology for building web ontologies. First, many referents are things in the world that are amendable to being part of an ontology. Second, methods from ontologies provide techniques for the management of the hierarchical structure of many WPNs. WPNs provide a natural way for everyday users of the Web to build ontologies in an analogous way that they currently build hierarchies of Web bookmarks.

This use of WPNs provides an alternative and complementary methodology for the development of the Semantic Web other than the top-down methodology that hopes large organizations will come to agreement on standard ontologies for various domains. In contrast, the bottom-up methodology notices users are already creating rough and ready ontologies at home through their web searches, and storing them as bookmark hierarchies. The Semantic Web effort should not fail to capitalize on this behavior, and the WPN effort captures this behavior in a principled way compatible with current work in ontology development, and also attempts to solves the difficult ontology mapping problem by grounding ontologies in web pages and searches. This data (such as the WPN parameters and the content of the URIs in the WPN) will be valuable for many machine-learning techniques comparing ontologies and building ontologies, since more data almost always means better results in terms of machine-learning. WPNs brings together relevance feedback and knowledge representation.


There is much work to be done. Since WPNs have yet to be tested on a large scale, the exact form of the wpn: URI scheme, as well as the inventory of information included therein, cannot be confidently said to be optimal. Likewise the shape and contents of EWPNs will probably be in need of extensions and revisions.

To begin to gain practical experience with WPNs and EWPNs, a number of browsers need to have working WPN implementations, and WPNs for Mozilla is currently under development. The site www.webpropernames.org, currently exists for the further development of Web Proper Names, and on it are an XML Schema, a RDF Schema, and XML to RDF and XML to RDDL HTML XSL transformations for EWPNs.

WPNs are one proposal for addressing the problem of reference for the Web. This problem is fundamental for the Web, involving crucial aspects of co-reference and identity. The Web Proper Name proposal, by making a clear distinction between a referent and web pages about that referent, adds to the conceptual apparatus needed to tackle this problem. By offering a series of concrete formats, applications that exploit this distinction can be built. It is in all our best interest, from the everyday user to professional ontologists, to put reference, in all of its mystery and power, back into the Web.


Thanks to Karen Spärck Jones and Norm Walsh for comments, as well as the feedback by participants in www-rdf-interest@w3.org, www-tag@w3.org, and many others.


J. Borden and T. Bray.
Resource Directory Description Language.
Technical report, RDDL Group, February 18 2002.
F. Drake.
The XML Bookmark Exchange Language.
October 28 1998.
G. Frege.
Uber sinn und bedeutung.
Zeitshrift fur Philosophie and philosophie Kritic, 100:25-50, 1892.
N. Goodman.
Languages of Art: An approach to a theory of symbols.
Hackett Publishing, 1976.
R. Guha.
Semantic Negotiation: Co-identifiying Objects across Data Sources.
In In Proceedings of Semantic Web Services Symposium, Palo Alto, CA, 2004.
S. Harnad.
The Symbol Grounding Problem.
Physica, 1990.
I. Jacobs.
Architecture of the World Wide Web.
W3C, July 5 2004.
M.-R. Koivunen, R. Swick, J. Kahan, and E. Prudhommeaux.
An Annotea Bookmark Schema.
S. Kripke.
Naming and Necessity.
Harvard University Press, 1972.
D. Lenat and E. Feigenbaum.
On the thresholds of knowledge.
In In Proceedings of International Joint Conference on Artificial Intelligence. 1987.
L. Masinter.
Dated URI and Thing Denoted By URI scheme.
IETF Draft, 2004.
B. Russell.
On Denoting.
Mind, 14:479-493, 1905.
J. R. Searle.
Proper Names.
Mind, 67:166-173, 1958.
B. C. Smith.
The Owl and the Electric Encyclopedia.
Artificial Intelligence, 47:251-288, 1991.