Following on from an earlier post about BPR3, I've got the Postgenomic documentation page updated so that it recommends using the rev="review" attribute on links in order to say "the current page/blog post is a review of the paper at this link", even when multiple papers are referenced in the review.
The reason it previously only recommended using rev="review" when talking about a single paper was so that an aggregator could say "this piece of text is a review of this paper". The alternative was hreview, to markup sections of a blog post that each reviewed different papers. However I think the hreview approach is complicated and an unnecessarily difficult barrier to usage, so it would be better to just use rev="review" as many times as necessary within a post.
Aggregators like Postgenomic will use the URL of the linked article to determine whether the thing being reviewed is a peer-reviewed paper or not, and to look up the metadata for that article. There is one thing possibly missing here, which is if the linked paper is found on an author's homepage, or in an institutional repository, or somewhere else outside the original publisher's site. In this case, there may also be a need for a rel attribute that would say "the document that this link points to is a peer-reviewed scientific paper". rel="bpr3" maybe, or something more general, semantically?
Comments
All fields are optional, email address will not be shown; no HTML, URLs are automatically hyperlinked.
Neat, I like it. It's really nice to have a simple alternative to hReview, and rev=review is a memorable and elegant solution.
The peer-reviewedness issue seems kind of thorny. Can you assume that because a rev=review link points at a publisher site that the item was peer-reviewed? The nature of traditional peer-review (more like pre-publication-review) in the context of a web of documents that have rev=review links is kind of blurry. I mean, if a particular URL is a supernode target for a bunch of rel=rev links what better indicator of peer review is there? :-)
Thanks for the update, Alf, and for the further detail on how the metadata is acquired by PG. I can see that using rev="review" accomplishes essentially the same thing as tagging your post with a unique "peer-reviewed research" tag, but on a per-link level instead of a per-post level.
Unfortunately, there's really no good way to make sure the links only point to research that's actually peer-reviewed without keeping a server-side list of publishers and enforcing a constraint that links must be to the publisher's site. Obviously this works for PG, but is it worth getting hung up on this? What about letting the blogger assert whatever they like with a rel attribute in a link that points whatever they like?
I can understand your not wanting to use blogger-contributed metadata, because there can always be errors and I don't guess it's something that very many people would do, anyways. Adding COinS is pretty easy, though, and if you use a COinS generator(which the bpr3.org people are working on: http://distributedneuron.net/bpr/citation.php ) to look up your info from a DOI or PMID, you won't have typing errors.
Mr Gunn: for "make sure the links only point to research that's actually peer-reviewed with a rel attribute in a link that points whatever they like", that's what I was getting at with the last paragraph in the post. You could let bloggers "assert whatever they like", but the rel attribute has to be in some standard format otherwise aggregators won't know what they mean.
Adding COinS is fine, but it's mostly useful for generating links; there's no way of attaching COinS metadata to a particular object. If you're using COinS to provide metadata that's harvested with human intervention then that's fine, but it's not much use to machines for that purpose.
I see your point about COinS. There's no way to say that a particular link goes with a particular COinS tag. Theoretically, you could use DOI links, encode the DOI in the COinS, and then match the two, but of course, there's no one actually doing that( as far as I know).
It's been very confusing for me trying to work out what method has the most general support now, most general applicability, and is most likely to be generally adopted by aggregators and bloggers.