Category review

Ratings

In the discussions related to RVW is on the scale used for the rating. And what to do with unrated items. For now the choice has been made to use of percentages.

In find this discussion touching upon a very general subject: scales, names and values. Using percentages is OK, but still limited. What if I want to use a 7-point scale? ANd what if I want to specify the meaning of each scale point? And what about the unrated?

This is a subject that must be solved elsewhere. I find it an XML-problem: how to specify scales (ordinal, nominal), values (integer, real, percentages), etc. And there should always be a way to specify [cite]undefined[/cite]. Hasn’t this been done?

Categories/tags: review
PermaLink • Comments • TrackBacks

OpenReview

I had a look at the Review-extensions that Alf Eating has been proposing. His proposal covers various publication standards such as RSS 1.0, RSS 2.0 and Atom. As his proposal does not explain the how and why, I will try to analyse it here and see if I understand it.

I notice only a limited number of Review namespace elements, such as: rvw:item, rvw:rating, rvw:buylink, rvw:sections, rvw:subject and rvw:content. I assume that the main culprit are the standards and their limits (and the fact that I partially inderstand it). What I miss is a description of an OpenReview namespace. I try to construct it from Alf’s proposal. An OpenReview thus contains the following fields:

• Author - this is the person that wrote the review. Why isn’t this the same as dc:creator, i.e. the definition creator in the Dublic Core?
• Title - the title of the review. The definition is probably the same as the Dublic Core definition. So the definition is inherited from there (is that possible?).
• Content - this is the actual review.
• Reviewed Item - the item that is reviewed. It would be great if this is an unique identifier. For books this would be the ISBN-number. Alf’s proposal adds the possibility to put multiple identifiers in order to create alternatives. Possible identfier spaces are ISBN, UPC, IMDB, ASIN;
• Rating - a rating as a percentage;
• Permalink - a permanent link to the review;

Alf’s proposal found the need to make my first guess more complex:

• Extended author - I had the simple idea that just the name of the creator would suffice. In an ideal world this would be a unique identifier. By adding the possibility to structure this field one can add more information (which?) that makes the identification more unique. Maybe multiple possibilities should be possible here, such as the link to the creator’s FOAF-file?
• Multiple Items - A review could discuss multiple items in one go. I gues that this is a valid addition, which copies the real world. It implies that it must be possible to add multiple identifiers to a review.
• Related Links - A number of links have been added to the review. One seems to be the permalink, but a human readable webpage. The others seem to be links related to the review. These links seem to be a good idea;
• Structured Item - Instead of just an identifier Alf’s proposal contains a structured item. In addition to the identifier fields such as dc:type, dc:subject, dc:creator, dc:title can be added. This helps identifying the item. Just an identifier is not Human friendly. So it does not do any harm and might be good idea. Does a dc:item exist?
• Rating - The ratings are embedded in the items. This allows for a rating per item in reviews that contain multiple items. But why contaminate item and review? Item should be limited to a description of the item only;
• Buylink - while this a very useful item, it has nothing to do with reviews. It is more part of the item than the review. Ideally it would come from a different namespace. Is there already a namespace for vendors of items?
• Thumbnail - nice addition to the book identifier;

A specific problem that was solved nicely was the idea of multiple items discussed in a single review. By adding multiple items to a review, fields that are specific for an item can be pushed down and specified uniquely. The fields that are missing are than inherited from a higher level.

I get the impression that Atom allows for more complex namespaces. It seems that RSS (and Atom a bit) require certain fields to be present. Fields that belong to the review are now RSS-/Atom-fields. Title, description, author and link should belong to the review and not to the feed. Although one could use inheritance here as well. Can these formats be used for the publication of any microcontent or will there be confusion on the meaning of the fields?

The publication of a list of reviews needs a separate discussion.

Categories/tags: review
PermaLink • Comments • TrackBacks