vote-links-faq

From Microformats Wiki
Jump to navigation Jump to search

VoteLinks Frequently Asked Questions (FAQ)

This page documents questions and answers regarding VoteLinks.

See the rel-faq for more general questions about using the rel and rev attributes.

Q: Why only for and against? How about something more nuanced?

A: The point of this is to provide a strong yes/no response. Finer-grained measures of agreement don't make much sense on an individual basis; aggregating many votes is more interesting. For example, consider how eBay's user rating system has been reduced to a like/dislike switch by users. The 'Ayes, Noes, abstentions' model has served well in politics and committees, when a division is called for.

Q: Aren't there much richer ways to express this idea and similar ones using RDF and semantic web ideas?

A: Indeed there are, but typing them by hand and remembering them is beyond most mere mortals, and automated tools don't do this either. This is meant to be very simple, memorable and easy to type in the current generation of blogging tools, that largely need manual entry of URLs. Similarly, it is easily added to an automated tool.

Q: How do you show a visual representation on the page of these different types?

A: You can do that by defining 'vote-for' 'vote-against' and 'vote-abstain' CSS2 attribute selectors and applying them to the post as well. E.g.

a[rev~="vote-for"]     { background:lime }
a[rev~="vote-against"] { background:red }
a[rev~="vote-abstain"] { background:gray }

Q: Won't all this negativity lead to trolling and flame wars?

A: Trolling is a problem already - Google's PageRank rewards being linked to, so notoriety is valued as highly as popularity. This leads to a 'no publicity is bad publicity' approach. For relentless positivists, the 'vote-against' and 'vote-abstain' values could be taken as signals meaning "don't index this link". For Vote tallying, however, positive and negative responses are both valuable and clear. The possibility of a personally filtered search, which reflects your own values expressed by your own links is greatly enhanced by the ability to define negative links as well.

Q: Could you add a css style rule for thumbs-up/thumbs-down/thumb flat icons?

A:

a[rev~="vote-for"]:after { content:url(thumbs-up.png) }
a[rev~="vote-against"]:after { content:url(thumbs-down.png) }
a[rev~="vote-abstain"]:after { content:url(thumbs-flat.png) }


Q: Could you use a period as the separator in your 'vote' rels, so you would have 'vote.for', 'vote.against', and 'vote.abstain'? The reason being interoperability with prior art, specifically Dublin Core with their 'DC.whatever". They (DC) even have an RFC which describes this prefixing mechanism, albeit with the <meta> element, not the <a> element.

A: You have misinterpreted the "-" in the values, which just serves to hyphenate in lieu of just leaving a space between the words in the values. Values in the 'rel' attribute cannot contain spaces themselves because the 'rel' attribute as a whole is a space separated set of rel values.

There is no interoperability issue here, merely a convention that one particular namespace-camp has adopted. If VoteLinks were to adopt something similar to the "DC." convention, then values might be something like 'VL.vote-for', 'VL.vote-against', 'VL.vote-abstain'. At this point there is no need for such namespace syntactic vinegar, so therefore we're going to keep it simple and just stick to the plain human readable values. For followup Q&A about VoteLinks and namespaces, see NamespacesChickenLittling.


Q: Why not use nouns and keep with the current 'rel' idiom? EtanWexler

A: The values are all nouns.

Q: Okay, so 'vote-for' means "a vote for", not "to vote for". The current idiom holds that "[ starting anchor of link ] has [ properties described by 'rel' ] which are [ ending anchor of link ]." and that "[ ending anchor of link ] has [ properties described by 'rev' ] which are [ starting anchor of link ]." For example, <link rel="index" href="http://example.com/an_index_for_Document_1"> in an HTML document at http://example.com/Document_1 means that "<http://example.com/Document_1> has an index which is <http://example.com/an_index_for_a_Document_1>". Suppose that there is a thesis, <http://example.com/thesis>. Suppose that there is a commentary, <http://example.com/commentary>, which agrees with the thesis. Suppose that the commentary contains a link to the thesis via the fragment <http://example.com/commentary#a_link> Suppose that the commentary's author wishes to assert within <http://example.com/commentary#a_link> that "<http://example.com/thesis> has a vote of agreement which is <http://example.com/commentary#a_link>". The proposed VoteLinks terms fit better with the 'rev' attribute (reverse relationship) than with the 'rel' attribute (forward relationship). The proposal still breaks from the current idiom. Is this an Earth-shattering discrepancy? No. Is this a wart? Yes. Is it better to cure warts early in the life of a specification than to attack those warts at some later time? Yes. So, to come back to asking a question, Is there any wiggle room at Technorati on the terms or on the choice of attribute? —EtanWexler

A: EtanWexler is correct. Further analysis of the HTML4 specification, of the existing 'rel' values, etc. has led me to come to the same conclusion as Etan. 'rev' is more appropriate than 'rel' and thus VoteLinks has been changed to use 'rev' instead of 'rel'. See the ["RelFAQ"] for more analysis. Thanks very much for this feedback, and thanks for your patience while we figured it out as well.

Q: Is a VoteLink to a page a vote for/against etc. that page, or what that page represents?

A: VoteLinks does not specify whether the vote applies only to just the page that is being linked to, or to what the page being linked to represents, e.g. a page on Amazon representing a book for example, or both. We are leaning towards the more inclusive consideration of the having the VoteLink refer to both the page and what the page represents. We expect implementation and authoring experience to help shape and refine the answer to this question.

Q: Is there any implementation suggestions for using VoteLinks on POST requests (html forms) instead of GET requests (a tags)? When voting this is often adding/modifying the server in some way so sending a GET request seems quite wrong.