[TagCommons-WG] Rel-tag

[Kevin Marks]

On 3/7/07, Tom Gruber <onto at tomgruber.org> wrote:
>
>  The first negative issue is only that it ignores the Semantic Web, which
> is a pretty good fit for this sort of thing.  The GRRDL effort makes this
> point moot.
>

Jolly good.

The second is based on my experience at implementing it.  Very consciously,
> rel-tag gives meaning to the inner structure of the URL and the anchor text
> over it.  The inner structure is that it requires that the last "segment of
> the path" is a string that is not a query parameter and that this string is
> the same as the tag label.  In other words, the URL referring to the tag has
> to be of the form
>
>             http://tagspace.com/.../tagname
>
> and *not*
>
>             http://tagspace.com/myTagProcessingPage?name=tagName
>
> or
>
>             http://tagspace.com/myTagProcessingPage?id=tagID
>
>
>
> This means
>
>
>
> (1) the technology for implementing the web site *must* have URL rewriting
> rules that can handle arbitrary path components like this.  Although it is
> the fashion for Web 2.0 sites to use Ruby and Rails or PHP/Apache with
> mod-rewrite rules that do this sort of thing, it is not the default way for
> web servers to take data as arguments.  Also, I thought according to the
> standards, URLs were nominal data (tested only with equality), and that only
> the left part (host and protocol) has any operational semantics.
>
This is not true; you can use an extrenal tagspace, which was the original
design centre -using flickr or del.icio.us or Technorati or Wikipedia urls
as tagspaces. If you think of tags within tagspaces as directory paths, this
is a very natural idiom, and it follows established practice at these
popular web 2.0 sites.

> (2) the string value of the tag *label* is also its *identifier*.  This
> violates a basic principle of software engineering -- the separation of data
> from UI.   For example, if you encode the elements of a drop down menu with
> variables having the same name, as soon as you change your mind about the
> names you unwittingly break your program.   In my system, tags were
> frequently renamed (eg, when they were misspelled), and if they had gotten
> out into rel=tag links, I would need to support all previous spellings for
> all time in order to not break the links.
>
If desired, you can do this redirection at the http layer, much as wikipedia
does with alternative spellings.

(3) A more fundamental consequence of the label=identifier for sharing tag
> data across heterogeneous systems is that by necessity the rel-tag format
> *forces* the system to be case sensitive, space sensitive, word morphology
> dependent, and otherwise enforcing the identity between the tag surface UI
> representation in a language with its machine-readable data identity.  Or,
> more precisely, systems that support many labels for the same tag would need
> to handle the multiple URLs of the same tag with redirects to a canonical
> page or many-to-1 URL/content mappings, which happen to anger the search
> engines and are therefore a bad idea for Web 2.0 or other companies
> depending on user contributed data and organic search.
>
The behaviour of a tagspace is independent of the urls used  - you will
notice that flickr and technorati do do space and case folding for tags, so
you see the same results at the urls for this. The behaviour is up to the
tagspace to implement - you can use one of these if thats what you want, or
implement your own if you care about the differences.

This doesn't anger search engine that I know of - many technorati tag pages
rank quite highly in search engines.

I know, this is one of the clever features of the design and is intended as
> an antispam technique.  However, experience also shows that it is rather
> hard to prevent spam with a pattern or convention.
>
It is impossible to prevent spam with anything other than a narrowly trusted
whitelist; making potential spammers pay the 'cost' of a link is a fairly
good mitigation tool.

I am afraid I don't have a constructive solution within the microformats
> pattern that overcomes my objections, which is why I have not spoken up on
> the microformats site.  However, I can see how we could deal with these
> objections by not promising any kind of "round trip" in expressive power
> between arbitrary tag data expressible in on ontology and the rel=tag
> format.  For instance, I don't see any way of a person tagging content on
> someone else's web site in a rel-tag, and we clearly have use cases for
> that.  That just means that the rel-tag format would only be suitable for
> the subset of tagging situations where the content is HTML controlled by the
> tagger (like a blog) and where the label=string=identifier assumptions hold.
>

rel-tag is deliberately minimal, so that extra meaning can be added by it's
inclusion in other microformats. xfolk and hReview have specific examples of
this, while rel="directory" adds a scope change. If you embed the rel-tag
within hAtom, you can have scoped authorship there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tagcommons.org/pipermail/wg-tagcommons.org/attachments/20070308/b80344a9/attachment-0004.htm>