[TagCommons-WG] Rel-tag (2nd try)

Thu Mar 8 05:53:15 PST 2007

(Sorry if this comes twice. My e-mail seems to be not behaving, it does 
show I sent this, but it does not appear on the list. I hope there are 
not many other messages like this.)

I think sometimes it makes sense for the author to attach the metadata
directly on a document it refers to but I'm not sure if I understand all
the aspects and goals of the microformat use case here? For instance, is
is important that the tags are embedded in the same document or just
that the author of the document can provide that information as part of
the authoring?

Here are some thoughts:

1) I think eventually we need to be able to add any RDF on a page not
just bits and pieces like in the microformats. But thats W3C
standardization. Most often though it is enough to add link to a
separate file containing the (RDF) metadata and that can be done already.

2) Even without the microformats, the author of the document can help
tagging parts of the page by providing IDs to the structures. Then the
URIs including the ID or XPointers that utilize the IDs can be used to
add the tag metadata to them. We used XPointers with Annotea annotations
and somewhere in my list is to explore this with the bookmarks and
tags/topics in Annotea Ubimarks.

3) Why convert HTML to tags instead of doing what I did with Annotea
when I converted documents (and here maybe also parts of documents)
containing links under categories (=tags/topics) to bookmarks? You can
easily transform the bookmark files to HTML and use different styles in
presenting them.

Marja

Tom Gruber wrote:
>
> 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 
> <mailto: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.
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> WG mailing list
> WG at tagcommons.org
> http://lists.tagcommons.org/listinfo.cgi/wg-tagcommons.org
>   