I-Tag Specification Working Draft 02

From ITags

Working Draft 02, 23 January 2006

Document identifier: i-tag-working-draft-02
Location: http://itags.net

Editors:
Drummond Reed, Cordance, http://xri.net/=drummond.reed
Andy Dale, ooTao, http://xri.net/=andy.dale
Mary Hodder, Dabble.com, http://xri.net/=mary.hodder
Kaliya Hamlin, PlaNetwork, http://xri.net/=kaliya

Contributors:
Gabe Wachob, http://xri.net/=gabew

Abstract
This document specifies a format for a new type of structured tag called an i-tag (identity tag). I-tags, like standard tags, are identifiers used to describe and categorize blog posts, images, songs, videos, or other digital objects. However i-tags can also take advantage of the capabilities of the OASIS XRI (Extensible Resource Identifier) specifications for structured identifiers. So i-tags can be persistent, can be verified, and can be separated from the digital object they describe without losing any information or verifiability.

Status
This is a working draft document that is expected to continue to evolve. It is produced is produced by volunteer contributors to the i-tags project at http://i-tags.net.

Review and contributions are welcome from anyone interested in the project.

Comments should be posted to an appropriate page of the i-tag wiki at http://i-tags.net or may be submitted to the editors via their contact pages listed above. A dedicated mailing list is also planned; watch the i-tags wiki for details.

IPR
This is an open, public, royalty-free specification. To the best of the knowledge of the editors and contributors, use or implementation of this specification does not infringe on any intellectual property rights.

Table of Contents

Contents 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Terminology and Notation 1.4 Keywords 1.5 Examples 2 Design Specifications 3 I-Tag Format 4 Identifier Formats 5 Identifier Requirements 5.1 The REL Identifier (RDF Predicate) 5.2 The HREF Identifier (RDF Object) 5.3 The CLASS Identifier (RDF Subject) 6 XRI Identifier Requirements 6.1 Using an XRI as the HREF Identifier for a Topic Tag 6.2 Using an XRI as the HREF Identifier for a License Tag 6.3 Using an XRI as the CLASS Identifier 7 I-Tag Community Dictionaries = 7.1 Dictionary of Digital Object Types (Preliminary) 7.2 Dictionary of Creative Commons License Types (Preliminary) 8 Examples 8.1 Topic Tags 8.1.1 Using URLs (HTTP URIs) 8.1.2 Using HXRIs (HTTP XRIs) 8.2 License Tags 8.2.1 Using URLs (HTTP URIs) 8.2.2 Using HXRIs (HTTP XRIs) 9 I-Tag Verification 10 Security and Privacy Considerations 11 Future Work 12 References 12.1 Normative 12.2 Informative

Introduction

Purpose

The purpose of the i-tag specification is to define an open, interoperable tagging format that meets the following requirements:

• Object independence: enable a tag to be used and verified even if separated from the digital object it describes.

• Verifiability: enable the link between the tag author and the digital object described by the tag to be verified.

• Resolvability: enable tag authors to control resolution of the tag via any tag dictionary, including the author’s own dictionary(s) (e.g., blog, website, or dictionary server); other author’s tag dictionary(s); a shared community or global tag dictionary such as Wikipedia or XDI.org.

• Dictionary services: enable tag dictionaries (individual, community, or global) to provide services for helping both tag authors and tag searchers identify the intended meaning of a tag and find potential synonyms, both in the original language and optionally in other languages.

• URI, IRI, and XRI support: enable i-tag authors and categories to be uniquely identified by either URIs (e.g., HTTP URIs, often called URLs), IRIs (internationalized URIs) or XRIs (often called i-names and i-numbers).

• Extensibility: enable tags to be extended to describe not just the topic with which a digital object is associated, but also other types of relationships, such as licensing terms, ratings, etc.

• Compatability: enable tags to be processed by existing tag infrastructure and specifications such as Rel-Tag.

Scope

This specification covers two types of i-tags:

• Topic tags are used to specify the topic or category that describes the content of a digital object. This is presently the predominate use of tags and the only type of tag currently supported by the rel-tag microformat. I-tags support multiple tag types, with topic tags being just one type.

• License tags are a new type of tag used to specify the license under which a digital object is available. This specification defines a set of license tags based on the licenses defined by Creative Commons.

Since i-tags are extensible, they may be extended to any type of statement or assertion about a media object, including ratings, reputations, distribution channels, etc. See section 11, Future Work.

Terminology and Notation

To specify i-tag syntax, this specification uses the syntax notation employed in IRI: Augmented Backus-Naur Form (ABNF), defined in RFC 2234. All ABNF productions not defined in this specification are defined in either RFC 2234, XRI Syntax or XRI Resolution.

This specification also uses the XRI glossary as specified in Appendix C of XRI Syntax.

Keywords

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. When these words are not capitalized in this document, they are meant in their natural language sense.

Examples

All i-tag examples in this specification are shown as follows.

	This is an example.

In order to avoid conflict with functioning identifiers, all examples in this specification that need to refer to specific (vs. generic) resources use DNS names or XRI identifiers reserved for examples whenever possible (usually strings beginning with the text, “example”.)

Design Specifications

Editor’s Note: The use cases, wireframes, and other design specifications will be forthcoming in a subsequent Working Draft.

I-Tag Format

The format of i-tags is based on:

• The rel-tag format from microformats.org. The i-tag format is a superset of the rel-tag format.
• The subject-predicate-object metadata model employed by RDF (Resource Description Framework).

An i-tag MUST conform to the following format:

	<a href="object" rel="predicate" class="subject">text</a>

In this format:

1. The href attribute is REQUIRED, and its value identifies the object of the RDF statement asserted by the i-tag, i.e., the tag value being applied (the topic name, license name, rating number, etc.)
2. The rel attribute is REQUIRED, and its value identifies the predicate of the i-tag statement, i.e., the type of tag being applied (a general tag, a license tag, a ratings tag, etc.)
3. The class attribute is OPTIONAL if the i-tag is "inline" (i.e., included within the digital object it describes), but REQUIRED if the i-tag is or will be separated from the digital object it describes. The value of this attribute identifies the subject of the i-tag statement, i.e., the digital object (blog post, photo, song, video) being tagged.

Note: the class attribute was selected from the possible "a" tag attributes because it accepts a string of type CDATA and thus can accommodate a URI, IRI, or XRI.

Identifier Formats

For broad compatability, i-tag attribute values may use all standard Web identifier formats. However i-tags offer additional features when used with the XRI (Extensible Resource Identifier) format for structured identifiers defined by the OASIS XRI Technical Committee.

In the i-tag format defined above, the identifiers used as the value of the href and class attributes (i.e., the object and subject of the i-tag) MUST be either:

1. A URI as specified in RFC 3986.
2. An IRI as specified in RFC 3987.
3. An XRI as specified in XRI Syntax 2.0.
4. An HTTP XRI (HXRI) as specified in XRI Resolution 2.0 (note that this is still a work-in-progress.)

In order for click-through behavior of an i-tag to be predictable, when an XRI is used as the value of the href attribute, it SHOULD be HXRI format unless it is known that the i-tag will only be consumeed in a context that supports native XRI resolution.

Lastly, in order for an i-tag to be verified as defined in this specification, the value of its class attribute MUST be either:

1. An HTTP URI or IRI as defined by RFC 2616.
2. An HTTPS URI or IRI as defined by RFC 2818.
3. An HTTP XRI (HXRI) as specified in XRI Resolution 2.0.

Identifier Requirements

The REL Identifier (RDF Predicate)

The value of the rel attribute MUST be:

1. tag for a topic tag.
2. license for a license tag.

Note: while these strings are the only values of the rel attribute specified in this version of the specification, future versions may allow this value to be an XRI or HXRI, particularly from the + namespace reserved for community dictionaries, in order to provide for extensibility.

The HREF Identifier (RDF Object)

For backwards compatability with the rel-tag format, when the value of the rel attribute is tag, the final path segment of the identifier used as the href attribute value MUST be the topic tag value. Examples:

<a href="http://example.com/tags/dog" rel="tag" class="http://example.com/blog/post/54">dog</a>

<a href="http://xri.net/=example.person/(+tag)/(+dog)/dog" rel="tag" class="http://xri.net/=example.person*blog/(+post)/54">dog</a>

See the rel-tag specification for more examples.

The CLASS Identifier (RDF Subject)

If present, the value of the class attribute MUST be an authoritative address for the digital object that is the subject of the i-tag. This class identifier MUST resolve in order to verify the i-tag (see below).

XRI Identifier Requirements

As identifiers, XRIs offer features such as persistence and standardized metadata that make i-tags more useful. This section specifies additional requirements that apply when an XRI or HXRI is used as the value of the href or class attributes.

Note that for an HXRI, these requirements apply to its embedded XRI, i.e., the XRI that follows the XRI proxy resolver prefix. Examples:

	http://xri.net/=example.author/(+tag)/(+dog)/dog
	<---prefix---><---------embedded XRI----------->

	http://xri.net/xri://@example*blog/(+tag)/(+dog)/dog
	<---prefix---><-----------embedded XRI------------->

Also, as shown by the first example above, the scheme name and double slashes xri:// are optional in an absolute XRI that begins with a global context symbol (=, @, +, $, or !). See the XRI 2.0 FAQ for more information about global context symbols.

Using an XRI as the HREF Identifier for a Topic Tag

The following rules apply to an XRI or HXRI used as the value of the href attribute when the value of the rel attribute is tag.

1. The authority segment MUST identify the authority for the tag dictionary or "tag space".
2. The third-to-last subsegment MUST be the XRI cross-reference (+tag) identifying the object type as a tag dictionary.
3. The second-to-last subsegment MUST be an an XRI cross-reference to the + namespace reserved for community dictionaries (see below).

Examples:

	http://xri.net/=example.author/(+tag)/(+dog)/dog
	               <--authority--><-type-><-tag->

	http://xri.net/xri://@example*blog/(+tag)/(+dog)/dog
	                    <--authority-><-type-><-tag->

Using an XRI as the HREF Identifier for a License Tag

The following rules apply to an XRI or HXRI used as the value of the href attribute when the value of the rel attribute is license.

1. The authority segment of the XRI MUST identify the authority for the license dictionary (e.g., Creative Commons).
2. The next-to-last subsegment MUST be the XRI cross-reference (+license) identifying the object type as a license dictionary.
3. The last subsegment MUST uniquely identify the license within the license dictionary using an XRI cross-reference to the "+" namespace reserved for this purpose.

Example:

	http://xri.net/@creative.commons/(+license)/(+public.domain)
	               <---authority---><---type--><---license----->

For more examples see the Creative Commons license dictionary below.

Using an XRI as the CLASS Identifier

The following rules apply to an XRI or HXRI used as the value of the class attribute regardless of the value of the rel attribute.

1. The authority segment of the XRI MUST identify the author and optionally the source publication of the class digital object.
2. The next-to-last subsegment MUST be an cross-reference to a digital object type as defined by the community dictionary specified in the next section below.
3. The final subsegment (and any optional query component) MUST uniquely identify the digital object within the context of this digital object type.

In addition, all non-dictionary subsegments of the XRI SHOULD be persistent if the i-tag and i-tag verification for this digital object is intended to be long-lived. Note that if both persistence and human-readability are desired, a digital object may be tagged with two "synonymous" i-tags – one using human-readable but reassignable XRI subsegments and the other using persistent XRI subsegments.

Examples of reassignable XRIs that could be used as the value of a class attribute:

	http://xri.net/=example.author/blog/(+post)/54
	               <--authority-->     <-type-><-id->

	http://xri.net/@example*blog/(+post)/987
	               <-authority-><-type-><-id->

Examples of persistent XRIs that could be used as the value of a class attribute:

	http://xri.net/=!1234.5678.A1B2.C34D!9F58/(+post)/!54
	               <-------authority--------><-type-><-id->

	http://xri.net/@!23C2.8D45.EB18.0813!92FC/(+post)/!987
	               <--------authority-------><-type-><-id->

I-Tag Community Dictionaries =

XRI cross-reference syntax enables metadata to be included directly in the identifier for a digital object. Two standard sources for such metadata are:

1. Specified XRI dictionaries published by standards bodies using the "$" global context symbol reserved for this purpose. An example is the XRI Metadata 2.0 specification.
2. Community XRI dictionaries published by any community wishing to establish shared semantics using the XRI "+" global context symbol reserved for this purpose.

The following community dictionaries establish shared semantics for the digital object types and license types described by i-tags, respectively.

Dictionary of Digital Object Types (Preliminary)

The table below is a dictionary defining the type of digital object being identified by an i-tag. Note that this is a preliminary list intended for further discussion -- harmonization of this vocabulary is only possible with community input.

XRI Dictionary of Digital Object Types

XRI	Digital Object Type
+post	a single post within a blog
+blog	an entire blog
+webpage	a single web page within a website
+website	an entire website, i.e. a collection of web pages within the tree rooted on the home page
+image	a single image
+image.collection	a collection of images
+song	a single song
+song.collection	a collection of songs
+video	a single video
+video.collection	a collection of videos

Dictionary of Creative Commons License Types (Preliminary)

The table below is a dictionary of licenses for the intellectual property rights under which a digital object is available for license and reuse. This dictionary is based on the Creative Commons licenses available at http://creativecommons.org/license/. This dictionary is preliminary only; the editors and contributors intend to develop a final version in conjunction with Creative Commons.

XRI Dictionary of License Types

XRI	Reference to Creative Commons License Type
+public.domain	http://creativecommons.org/licenses/publicdomain/
+developing.nations	http://creativecommons.org/licenses/devnations/2.0/
+sampling	http://creativecommons.org/licenses/sampling/1.0/
+sampling.plus	http://creativecommons.org/licenses/sampling+/1.0/
+non-commercial.sampling.plus	http://creativecommons.org/licenses/nc-sampling+/1.0/
+founders.copyright	TBD (the Creative Commons site does not list a URI for this license)
+cc-gnu.gpl	http://creativecommons.org/licenses/GPL/2.0/
+cc-gnu.lgpl	http://creativecommons.org/licenses/LGPL/2.1/
+attribution-sharealike	http://creativecommons.org/licenses/by-sa/2.5/

Examples

Topic Tags

Using URLs (HTTP URIs)

<a href="http://example.com/tags/dog" rel="tag" class="http://example.com/blog/post/54">dog</a>

<a href="http://example.org/music/genres/blues" rel="tag" class="http://example.com/user/~mary/songs/bye-bye-now">blues</a>

<a href="http://en.wikipedia.org/wiki/dog" rel="tag" class="http://example.com/">dog</a>

Using HXRIs (HTTP XRIs)

<a href="http://xri.net/=example.person/(+tag)/(+dog)/dog" rel="tag" class="http://xri.net/=example.person/(+blog)/post/54">dog</a>

<a href="http://xri.net/example.org/(+tag)/(+music(+blues))/blues" rel="tag" class="http://xri.net/=example*mary/(+song)/!14">blues</a>

<a href="http://xri.net/@wikipedia/(+tag)/dog" rel="tag" class="http://xri.net/example.com/(+website)/example.com">dog</a>

License Tags

Using URLs (HTTP URIs)

<a href=" http://creativecommons.org/licenses/publicdomain/" rel="license" class="http://example.com/blog/post/54">dog</a>

<a href=" http://creativecommons.org/licenses/sampling+/1.0/" rel="license" class="http://example.com/user/~mary/songs/bye-bye-now">Bye Bye Now</a>

<a href=" http://creativecommons.org/licenses/by-sa/2.5/" rel="license" class="http://example.com/">All For Dogs</a>

Using HXRIs (HTTP XRIs)

<a href="http://xri.net/@creative.commons/(+license)/(+public.domain)" rel="license" class="http://xri.net/=example.person/(+blog)/post/54">dog</a>

<a href="http://xri.net/@creative.commons/(+license)/(+sampling.plus)" rel="license" class="http://xri.net/=example*mary/(+song)/!14">Bye Bye Now</a>

<a href="http://xri.net/@creative.commons/(+license)/(+ attribution-sharealike)" rel="license" class="http://xri.net/example.com/(+website)/example.com">All For Dogs</a>

I-Tag Verification

There are two cases in which an i-tag may need to be verified:

1. If the digital object containing the i-tag is not retreived from the identifier specified in the class attribute of the i-tag (but came from some other location).
2. If the i-tag is completely separated from the digital object it describes.

In both cases the solution is to verify the i-tag by resolving the identifier specified in the class attribute of the i-tag as follows:

1. Do a HTTP HEAD request on the HTTP(S) URI or HXRI contained in the class attribute.
2. To validate, the response MUST be an HTML HEAD element containing a LINK element whose attributes and attribute values are identical to those in the i-tag being verified.

Example:

To verify the i-tag:

<a href="http://example.com/tags/dog" rel="tag" class="http://example.com/blog/post/54">dog</a>

The verifying agent would make an HTTP HEAD request to:

	http://example.com/blog/post/54

The response must include the following:

...HEAD info...
<html>
	<head>
		<link href="http://example.com/tags/dog" rel="tag"
		class="http://example.com/blog/post/54">dog</a>
	</head>
</html>
...other HEAD info...

Note that if the value of the class attribute is an HXRI, XRI proxy resolution will be used as defined in XRI Resolution, however that will be transparent to the verifying agent.

Security and Privacy Considerations

Editor’s Note: This section is TODO. If you have a specific security or privacy question or concern that should be addressed, please bring it to the attention of the editors.

Future Work

The i-tag specification introduces a new dimension of structured tagging. The editors wish to keep the scope of the basic specification as confined as possible to encourage early and stable implementations. Specific i-tag types that were placed out of scope for the first version but which may be addressed in future versions include:

• Ratings tags
• Reputation tags
• Distribution tags

Another area of future work is the potential for i-tags to provide a verifiable format for "social tagging", i.e., tagging any URI-, IRI-, or XRI-identifiable digital object, not just an author's own objects.

If you have a potential use for i-tags that you'd like to see addressed in the specification, please contact the editors via their contact pages (listed at the beginning of this document).

References

Normative

RDF Primer 

F. Manola, E. Miller, RDF Primer, http://www.w3.org/TR/rdf-primer/, W3C Recommendation, February 2004.

Rel-Tag 

C. Tantek, Rel-tag Specification, http://microformats.org/wiki/rel-tag, January 2005.

RFC 2119 

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, March 1997.

RFC 2234 

D.H. Crocker and P. Overell, Augmented BNF for Syntax Specifications: ABNF, http://www.ietf.org/rfc/rfc2234.txt, November 1997.

RFC 3896 

T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt, January 2005.

RFC 3987 

M. Dürst, M. Suignard, Internationalized

Resource Identifiers (IRIs), http://www.ietf.org/rfc/rfc3987.txt, January 2005.

XML Schema v2 

P. Biron, A. Malhotra, XML Schema Part 2:

Datatypes Second Edition W3C Recommendation, http://www.w3.org/TR/xmlschema-2/, October 2004.

XRI Syntax 

D. Reed, D. McAlpin, Extensible Resource Identifier (XRI) Syntax V2.0, http://www.oasis-open.org/committees/download.php/15695, XRI Technical Committee Specification, November, 2006.

XRI Resolution 

G. Wachob, D. Reed, Extensible Resource Identifier (XRI) Resolution V2.0, http://www.oasis-open.org/committees/xri, January 2006. Note: still a Working Draft.

XRI Metadata 

D. Reed, M. Schleiff, D. McAlpin, Extensible Resource Identifier (XRI) Metadata V2.0, http://www.oasis-open.org/committees/xri, January 2006. Note: still a Working Draft.

Informative

XRIFAQ 

OASIS XRI Technical Committee, XRI 2.0 FAQ, http://www.oasis-open.org/committees/download.php/15695/xri-2%200-faq-2005-12-01.pdf, December, 2005.