A Uniform Resource Name (URN) Namespace for Tag Metadata
tag-urn.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 5, 2007.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

This document describes the Namespace Identifier (NID) for one URN which identifies the family of subject-tag metadata, and a family of URNs each of which identifies one subject tag.

Table of Contents

1.  Requirements notation
2.  Introduction
3.  URN Specification for "tag" NID
4.  Examples
5.  Namespace Considerations
6.  Community Considerations
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

In recent years it has become common practice to associate World Wide Web resources, in particular weblog postings, with "tags", which are short human-readable labels. These are similar in form and function to "categories", but differ in that they typically are not organized in a traditional taxonomic hierarchy. There is a wide variety of software which uses tags to support the search and display of Web resources.

The Atom Syndication Format [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) provides a "category" element for associating subject categories with Web resources. This element allows the specification of a "scheme", a URI [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) which identifies the vocabulary from which the category label is drawn.

This specification defines the "tag" namespace; a URN consisting of just "urn:tag:" is used to identify the vocabulary from which tags are drawn.

Additionally, for any individual tag, for example "beatles", the URN "urn:tag:beatles" may be served as a URI which identifies that individual tag.

This namespace specification is for a formal namespace.

3.  URN Specification for "tag" NID

Namespace ID:

tag

Registration Information:

Registration version number: 1

Registration date: 2007-02-01

Declared registrant of the namespace:

Registering individual:

Tim Bray

Designated contact:

Role: Registrant

Email: tbray@textuality.com

Declaration of syntactic structure:

The Namespace Specific String (NSS) of all URNs that use the "tag" NID will have the following structure:

urn:tag:{TagName}

Where the "{TagName}" is either empty, or is a US-ASCII string that conforms to the URN syntax requirements of [RFC2141] (Moats, R., “URN Syntax,” May 1997.).

If the NSS is empty, the URN identifies the vocabulary containing all possible tags. Otherwise, it identifies the tag encoded in the NSS. Tags may contain any Unicode characters; any such characters which are non-ASCII must be percent-encoded as described in [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

Relevant ancillary documentation:

None.

Identifier uniqueness considerations:

By design, anyone may choose any tag without consultation or co-ordination. The expectation is that community interaction will produce rough agreement on the appropriate tags to be used in identifying subjects, to the extent that the tagging will be useful.

However, there can be no confidence that any particular tag will be the only one used to identify a particular subject, or that any two identical tags were intended by those who used them to identify the same subject.

Identifier persistence considerations:

Tags are just strings whose meanings are expected to emerge from community interaction. Thus, their persistence is a social phenomenon based on community recognition. Likely, tags which are descriptive and short have an increased chance of garnering community support and thus longevity.

Process of identifier assignment:

Anyone may insert any tag in any Web resource at any time without any prior consultation or co-ordination.

Process of identifier resolution:

None defined, since a tag identifies an abstract subject, not a concrete object that can be retrieved.

Rules for Lexical Equivalence:

No special considerations; the rules for lexical equivalence of [RFC2141] (Moats, R., “URN Syntax,” May 1997.) apply.

Conformance with URN Syntax:

No special considerations.

Validation mechanism:

None required, beyond URN syntax considerations.

Scope:

Global

4.  Examples

A URN that identifies the vocabulary of subject tags:

urn:tag:

A URN that identifies the tag "beatles":

urn:tag:beatles

A URN that identifies the tag "cafe", where the trailing "e" has an acute accent:

urn:tag:caf%C3%A9

5.  Namespace Considerations

The current namespace of tags, expressed as a global pool of short textual strings assigned informally, functions well. However, there is currently no way for a document format such as Atom to specify that a category is one of these things. The URN "urn:tag:" fills this need.

There are many protocols and data formats where it is advantageous to be able to refer to something using URI syntax. This URN namespace provides a way to generate URI syntax for any informal subject tag.

6.  Community Considerations

The usefulness of tags as subject identifiers depends on informal large-scale co-ordination among the population of people who apply them, which includes but is not limited to those who create and post original content. No mechanism is contemplated or desired for formalizing this process.

7.  Security Considerations

There are no additional security considerations other than those normally associated with the use and resolution of URNs in general.

8.  IANA Considerations

(to be filled in at registration time)

9.  References

9.1. Normative References

9.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).