Re: Review structure

On Mon, Jun 16, 2014 at 01:59:19PM +0100, Alf Eaton wrote:
>On 16 June 2014 02:26, Dan Scott <dan@coffeecode.net> wrote:
>
>> On Mon, Jun 16, 2014 at 12:13:34AM +0100, Alf Eaton wrote:
>>
>>> I've been adding microdata markup to some reviews recently, as well as
>>> harvesting reviews from other sites, and have found that the current
>>> reviewBody and ratingValue properties are often too coarse-grained to
>>> properly describe the reviews.
>>>
>>> For example, this review of a restaurant has 3 separate aggregate rating
>>> values ("food", "decor" and "service"), but they're just marked as
>>> "ratingValue" with no way to distinguish between them using the microdata
>>> alone:
>>> http://www.zagat.com/r/kevin-rathbun-steak-atlanta

<snip>

>>> One solution I can think of would be to add a "reviewSection" property,
>>> having a "reviewSectionHeading",  "reviewBody" and "reviewRating", for
>>> each
>>> section of the review. There may well be a better solution, though…
>>>
>>> The AggregateRating class would probably need something similar (as in the
>>> Zagat example above).
>>>
>>> Does anyone know if this has been discussed anywhere previously, or
>>> whether
>>> there are analogous "section" properties in classes other than Review?
>>
>>
>
>> Hmm, interesting problem. If I was to constrain myself to existing
>> schema.org properties, I would consider simply separating each review
>> into three separate Review entities, using the existing "name" property
>> instead of your proposed "reviewSectionHeading".
>>
>
>That seems reasonable. Would the individual reviews then be "reviewSection"
>properties of one over-arching Review, with a shared author, date, review
>subject, etc?

That could work. I had thought about plugging the property "hasPart"
that SchemaBibEx proposed as part of the Periodicals/Articles extension
for connecting the subreviews to the over-arching review, in which case
it would look something like this:
http://stuff.coffeecode.net/schema.org/review_subreviews.html

But perhaps that would be too generic a relationship.

Dan

Received on Monday, 16 June 2014 13:25:59 UTC