<br><br><div><span class="gmail_quote">On 3/7/07, <b class="gmail_sendername">Tom Gruber</b> <<a href="mailto:onto@tomgruber.org">onto@tomgruber.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="blue" lang="EN-US">
<div><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">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.</span></font></div></div></blockquote><div><br>Jolly good. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="blue" lang="EN-US"><div><p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">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</span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> <a href="http://tagspace.com/.../tagname" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://tagspace.com/.../tagname</a> </span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">and *not* </span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> <a href="http://tagspace.com/myTagProcessingPage?name=tagName" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://tagspace.com/myTagProcessingPage?name=tagName</a></span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">or</span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> <a href="http://tagspace.com/myTagProcessingPage?id=tagID" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://tagspace.com/myTagProcessingPage?id=tagID</a></span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">This means</span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">(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. </span></font></p></div></div></blockquote><div>This is not true; you can use an extrenal tagspace, which was the original design centre -using flickr or
<a href="http://del.icio.us">del.icio.us</a> 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.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="blue" lang="EN-US"><div><p><font color="navy" face="Arial" size="2">
<span style="font-size: 10pt; font-family: Arial; color: navy;">(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. </span></font></p></div></div></blockquote><div>If desired, you can do this redirection at the http layer, much as wikipedia does with alternative spellings. <br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="blue" lang="EN-US"><div><p><font color="navy" face="Arial" size="2">
<span style="font-size: 10pt; font-family: Arial; color: navy;">(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.</span></font></p></div></div></blockquote><div>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.
<br><br>This doesn't anger search engine that I know of - many technorati tag pages rank quite highly in search engines.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="blue" lang="EN-US"><div><p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">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.</span></font></p></div></div></blockquote><div>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.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="blue" lang="EN-US"><div><p><font color="navy" face="Arial" size="2">
<span style="font-size: 10pt; font-family: Arial; color: navy;">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.</span></font></p></div></div></blockquote><div><br>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.
<br> </div></div><br>