[microformats-discuss] Ambiguities in reltag specification

[Ryan King]

On Jul 21, 2005, at 1:52 PM, Bud Gibson wrote:
> Hi Craig:
>
> Please stick with text (not html) on the list.  Let me see if I can  
> address some of these issues as I have wrestled with them recently:
>
>>> How would spaces be supported in this case?   My assumption is  
>>> through replacing spaces with "+", but this is not explicitly  
>>> stated.
>
> Perhaps somewhat implicit in the spec is that you would use  
> standard URL encoding practices.  It is after all a URL.

Yes, spaces can be encoded with a %20, just like any other URL.

>>> URLs are not the most convenient encoding for non-English languages

I'm not sure what exactly the issue is here. If you take a look at  
http://technorati.com/tags/?showall=1 you'll see that plenty of non- 
english speakers use rel-tag. Please let us know what you have in  
mind here.

> And not always for English.  One of the motivations in the spec  
> (per my very limited understanding) is that the tag point at a  
> specific repository about items on that topic.  Making the tag be  
> part of the URL helps guarantee this.
>
> At the aggregator level, making the tag explicitly part of the URL  
> also helps fight SPAM tagging since the tag is part of the pointer  
> (see next).
>
>>> Their is no guarantee that the apparent tag (the one displayed to  
>>> the user) and the real tag are the same.  This defeats the peer  
>>> pressure that is intended.

Not really. You can still see the link onhover and if you click on  
the link you'll see that it was not what the link-text indicated.

> The peer pressure comes at the aggregator level  Aggregators  
> aggregate links based on the value in the URL not the link text.   
> SPAM can then be reported if the tag is not accurate, and the  
> perpetrating site is also immediately ID'd.  At individual sites,  
> you are clearly in caveat emptor mode.
>
>>> No guidance is given as to whether or not having different link  
>>> text and tag value is considered bad form.
>
> For the most part, people make the two match.

Yes, most people make this identical, esp. when doing a list of tags.

OTOH, when doing inline tags, it is often beneficial to give a  
different text to the link (though usually synonymous). Look, for  
example at http://cs.usfca.edu/~rking/resume.html where I use tags to  
describe my skills. In several cases the text of the tag link is not  
identical to the tag, but it is often synonymous (b/c that's the best  
wikipedia page I could find).

>   The link text tends to be a readable form of the tag.  Having  
> spoken with the spec authors, they indicate that not following this  
> practice is also possible.

And is, at times, desirable.

>   I'm not sure what the use case is though.

See my resume example above.

>>> Have these things been addressed and are just not mentioned in  
>>> the wiki or am I just not getting it?
>
> Have you looked at the technorati or IceRocket help pages for tags?

No need to look at both.

-ryan

> On Jul 21, 2005, at 16:02, Craig Ogg wrote:
>
>> On reading the specification to things jump out as unclear.  Here  
>> is a modified version of the example from the spec:
>>
>>      <a href="http://technorati.com/tag/tech" rel="tag">apple</a>
>>
>> According to the spec, the actual tag is determined by parsing the  
>> URL. In the case it would be "tech" and not "apple."  This seems  
>> to me to lead to several problems:
>> Some tagging systems support spaces.  How would spaces be  
>> supported in this case?   My assumption is through replacing  
>> spaces with "+", but this is not explicitly stated.
>> URLs are not the most convenient encoding for non-English languages
>> Their is no guarantee that the apparent tag (the one displayed to  
>> the user) and the real tag are the same.  This defeats the peer  
>> pressure that is intended.
>> No guidance is given as to whether or not having different link  
>> text and tag value is considered bad form.
>> Have these things been addressed and are just not mentioned in the  
>> wiki or am I just not getting it?
>>
>> Craig