[TagCommons-WG] Rel-tag

Wed Mar 7 16:49:00 PST 2007

Hello,

Thanks for stepping up, Harry and Kevin.  I expect that we will form a
bridge to rel-tag microformats via GRRDL once we get our act together about
the conceptualization and how to handle variants of it.

Harry quoted me as having a "host of problems" with rel-tag. Actually, I am
on the whole very impressed with the effort and applaud its process.  And
the proposal is very cleverly designed for rapid uptake by DIY bloggers
without changing existing tools.  I only have two negative issues with the
details of the design. 

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.

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.  

(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.  

(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.

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. 

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.

Hopefully I got this wrong out of ignorance and someone can clear it up.  In
any case, we can certainly map from semantics to syntax as long as we are
explicit about the potential information loss in translation.

tom

  _____  

From: Kevin Marks [mailto:kevinmarks at google.com] 
Sent: Wednesday, March 07, 2007 3:17 PM
To: Harry Halpin
Cc: Tom Gruber; Tag Commons Working Group
Subject: Re: [TagCommons-WG] Rel-tag

On 3/7/07, Harry Halpin <hhalpin at ibiblio.org> wrote:

I'd like to draw focus onto rel-tag as a common starting place.

I might add, if we're interested in data-formats like RDF, GRDDL gives one
a way to bootstrap rel-tag data automatically into RDF (if we can get 
rel-tag to get a profile URI)..

Could you use 

http://microformats.org/wiki/rel-tag-profile

Tom mentioned to me offline that there were a host of problems with
rel-tag. Could someone iterate through them for me? 

yes, I'd like to hear them too

The main problem seems to be that there's not too much there, it's just a 
(a) between the page you are on and (b) the target of a link.

It's clearly missing, say, who tagged the page. However, the great thing
about RDF is you can just underspecify things.

your RDF tuple would be 

[url of tagged page] http://microformats.org/wiki/rel-tag-profile
http://tagspace.com/[tag]  <http://tagspace.com/%5btag%5d> 

What I'd like to do is to build a sort of "layer-cake" for tags, where at 
the bottom somewhere is the very basic data between between a page, a
tagged relationship, and it's tagged data. This could easily be put in an
API/RDF/XML.

Then, we can look at common services and see what else they provide, like 
identity of who tagged the page, time of tagging, language, etc. And then
add these in as "slots".

But first things first! Can we support the relationship of a tag as
between "one URI" and "another URI". 

Since in SemWeb world "one URI" could mean a person, then this mechanism
wouldn't necessarily exclude the idea of "people tagging pages" which I
think is much more intuitive than rel-tag's idea of "pages tagging pages". 

no, it's pages having tags - see above. The URL defines the tag. 

Then we can move up to deal with more complex cases like xFolk, Annotea
annotations, and the many issues Tom brought up in his folksonomy paper.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tagcommons.org/pipermail/wg-tagcommons.org/attachments/20070307/06bce254/attachment-0004.htm>