HellOnline

Icon

Eran's blog

i-Tags

i-Tag is a new standard proposal by Mary Hodder, Kaliya Hamlin, and Drummond Reed.

The basic idea of an i-tag (identity tag, independent tag, intelligent tag – take your pick) is that a user could tag an object on their own site (photo, video, sound file, text or an entire blog post), where the tag, and the object, would then go out through the RSS feed or be spidered, with some additional information that doesn’t now exist in tags.

Here is a sample i-Tag

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

This is an interesting idea but we already have xFolk that solves this problem pretty well, in my opinion. xFolk is a format for publishing collections of bookmarks, it allows users to apply rel-tag to any object identified by a URL. xFolk can be embedded in XHTML, Atom, etc. so it can be easily aggregated by any interested party. Here’s the same entry in xFolk:

<span class=”xfolkentry”>
<a class=”taggedlink” href=”http://example.com/blog/post/54″>my blog post</a>
<a rel=”tag” href=”http://example.com/tags/dog”>dog</a&gt;
</span>

The other option for i-Tag is tagging objects with a license. I fail to see a general use case for this that would not be covered by rel-license. A sample license i-Tag:

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

It might be useful to indicate the license of an image or a video clip in some cases but in those same cases one could use xFolk and rel-license to achieve the same:

<span class="xfolkentry">
<a class="taggedlink" href="http://example.com/blog/post/54">my blog post</a>
<a rel="license" href="http://creativecommons.org/licenses/publicdomain/">Public Domain</a>
</span>

Besides replicating existing work, there’s a couple of other problems with i-Tags. Embedding a URL (or XRI or what-have-you) in the class attribute strikes me as a generally bad idea.

  1. From a semantic standpoint, this is completely meaningless.
  2. From a design standpoint, you cannot use that class value as part of a CSS selector – it just doesn’t work. And am I allowed to add more values to the class attribute to fix that? The spec is unclear on this.
  3. Last but not least, this piece of data is completely hidden from whoever is viewing the page. How are my readers supposed to know what I’m tagging if they can’t see the subject URL?

As for the whole community dictionary thing (and whatever other information might be hidden inside those XRI), I’m not sure I quite follow but it seems like it would be just as useful inside xFolk and rel-license if one were inclined to use XRI. Alternatively, we do have wikipedia.

via: You’re It

Advertisements

Filed under: MicroFormats, Tagging, The Net

8 Responses - Comments are closed.

  1. […] ible, and were dissatisfied with some things with the Technorati tags.” UPDATE: Via Hellonline I see that the initiative is also the work of Kaliya Hamlin (another person with a lot of irons in th […]

  2. assaf says:

    As a good design principles, class names should be few and common, and maybe, I’m just guessing, related to the use of CSS to style the document. Names like ‘post’, ‘comment’, ‘tag’, even ‘xfolkentry’ work out nicely.

    They’re definitely not URLs not matter how you choose to interpret the HTML specification. That’s what id and href are for. Not that I mind people breaking the HTML specification, but I get to wonder: do they know something I don’t know, or do they just don’t know how to use the Web?

    At any rate, I’m waiting for this specification to be further developed and expanded on, so I can understand what new problem it’s trying to solve, before I can comment on what could be a good solution to that problem.

  3. Rowan says:

    I have no disagreement with your other points, and not much interest in i-Tag, but your comments about urls as class names have me a bit puzzled, as does the subsequent comment above. The two of you seem to be opposed to it on some vague religious grounds.

    “From a semantic standpoint, this is completely meaningless.”

    Isn’t it obvious that the meaning of a URL is the resource it refers to?

    “They’re definitely not URLs not matter how you choose to interpret the HTML specification.”

    Show me the bit of the HTML spec that is incompatible with URLs as class names.

    I’m just interested. Microformats might be better if they had full URIs as identifiers. It would make their creation distributed. Anyone could make a microformat under their own namespace. They would lose a little bit of their elegance and simplicity but those who are scared away by a URI don’t generally need to be looking at the code anyway.

  4. limbo says:

    Rowan, I’ve 3 major objections to that:

    1. Semantic – The different attriubtes in HTML elements usually come with some meaning. Rel and Rev show the relationship, alt gives alternate text, etc. The class attribute assigns a class name to an element usually used to specify the element’s role in the document (e.g. a navigational link as opposed to an external link). In the case of i-Tag the authors seem to be saying “this is a link of type ‘http://example.com/blog/post/54’.” I dont know what that means, do you?

    2. From a functional standpoint, class names are usually used as CSS selectors. It is impossible to use a URL as a CSS selector; Try it, you’ll see.

    3. As I stated before, this piece of data is hidden from the user. This is bad for several reasons, you can read about that in the rel-tag spec (which the authors claim to be a superset of).

    As for microformats, I don’t claim to represent the microformats community and the discussion on namespaces could go on forever and a day.

  5. limbo says:

    For more about hidden meta data see this post from Tantek.

  6. ryan king says:

    Microformats might be better if they had full URIs as identifiers. It would make their creation distributed. Anyone could make a microformat under their own namespace.

    Namespaces are an anti-goal of microformats. Namespaces cause more problems than they solve.

  7. assaf says:

    > Show me the bit of the HTML spec that is incompatible with URLs as class names.

    The HTML spec I have handy (4.01) defines the class attribute as cdata-list[CS]. The first part says it’s a whitespace separated list of cdata items, not specifically URLs. The second part says they are case sensitive, hence not URLs.

    URL equivalence ignores case for the scheme and authority part, so anything that imposes a case sensitive (or insensitive) restriction does not allow for the use of URLs.

    Not to mention that URL classnames are useless when it comes to CSS.

    Microformats go about their business without trying to find loopholes in the spec or interpret it in creative ways. They just apply more semantics to an existing use of the class attribute.

    As xfolkentry clearly shows, there are ways to solve the link pairing problem by containment. So when a specification proposes breaking HTML/CSS without due justification, I have to ask: why?

  8. Rowan says:

    Thanks, I understand where you’re coming from now. It’s impossible to use URL-classnames for the things classnames are usually used for. Plus the visible meta data point is well taken.

    “Namespaces are an anti-goal of microformats. Namespaces cause more problems than they solve.”

    Ok, I’ll take your word for it Ryan.

%d bloggers like this: