Consider merging h-review properties into h-entry

[barnabywalters]

There might be a case for either retiring the h-review vocabulary entirely, or at least making some h-review-specific properties explicit extensions of h-entry in order to encourage and support publishing content as .h-entry.h-review.

• h-review was already made compatible with h-entry (reviewer -> author, reviewed -> published, description -> content)
• In practice, only item, rating, best and worst are unique to h-review. All other properties are shared with h-entry.
• Publishing reviews as h-entry provides good back compatibility, as any feed reader which is able to display h-entries can show a basic representation of a review, and it’s easy for consumers to additionally handle some extra properties rather than having to handle a whole separate content type. Same for publishers — just like replies/comments/photos/videos/etc, reviews just become another h-entry.
• easy to provide back-compatibility for any consumers which do handle h-review: simply publish reviews as both h-entry and h-review

Open questions:

• How, if at all, should post type discovery change to detect reviews? Based on the presence of what property/ies?
• item is a very generic property name which doesn’t express the review-of relation. @dshanske suggested u-review-of to match other h-entry property names e.g. in-reply-to, like-of etc.
• What to do with h-review-aggregate? Probably just drop it entirely? https://chat.indieweb.org/microformats/2023-10-30#t1698698699541000

[dshanske]

I actually suggested review-of, which could be a u- property, or a nested h-item, or even a nested h-card for reviews of places. I think this is more flexible than h-review and less confusing.

[dshanske]

My WordPress implementation of Microformats has the post object representing h-entry...so having h-review as a top level object would require additional code i haven't gotten to.

Outputting an h-entry as a review with either a nested h-review or preferably, no nesting but a review-of property to aid with post type discovery would be preferable. I may implement this more readily.

[dshanske]

I have set up a test implementation of an h-entry with the review-of property, which I'll be deploying to my site to write reviews.

Proposed definition is:

'the URL which the h-entry is considered a review of, optionally an embedded h-cite, h-card, h-event, or h-item'

That would cover reviewing a place, event, item, or article/book/publication/etc.

[benjifs]

Based on the discussion at the most recent HWC Pacific, I updated my watched page to use u-review-of as well.

[capjamesg]

I am not sure I agree with this proposal. For context,m I publish h-entry across two separate sites and have consumed it, too.

Publishing reviews as h-entry provides good back compatibility, as any feed reader which is able to display h-entries can show a basic representation of a review, and it’s easy for consumers to additionally handle some extra properties rather than having to handle a whole separate content type. Same for publishers — just like replies/comments/photos/videos/etc, reviews just become another h-entry.

This relies on the available contents being easy to distinguish as a review, which may not be the case. Someone might say "I watched XYZ" in their post body, without a clear review. Thus, it may be interepreted as a post in a reader without h-review support. There is indeed a "graceful dehancement" that happens there where the main content is preserved but the semantics are lost, but I wonder the extent to which that is preferred?

[dshanske]

I am not sure I agree with this proposal. For context,m I publish h-entry across two separate sites and have consumed it, too.

Publishing reviews as h-entry provides good back compatibility, as any feed reader which is able to display h-entries can show a basic representation of a review, and it’s easy for consumers to additionally handle some extra properties rather than having to handle a whole separate content type. Same for publishers — just like replies/comments/photos/videos/etc, reviews just become another h-entry.

This relies on the available contents being easy to distinguish as a review, which may not be the case. Someone might say "I watched XYZ" in their post body, without a clear review. Thus, it may be interepreted as a post in a reader without h-review support. There is indeed a "graceful dehancement" that happens there where the main content is preserved but the semantics are lost, but I wonder the extent to which that is preferred?

Thus the proposed h-entry property that could be used to identify it as a review.

[gRegorLove]

I have a post with u-review-of now. I've included my rating as text within the e-content so social readers will display everything normally since it basically has the form of a blog post. The star rating is also marked with p-rating, so consumers looking for reviews can extract that information too.

Truncated mf2 parse of it. Note the review-of and rating properties.

"type": [
    "h-entry"
],
"properties": {
    "name": [
        "Geico: Zero Stars"
    ],
    "rating": [
        "0"
    ],
    "url": [
        "https://gregorlove.com/2023/12/geico-zero-stars/"
    ],
    "review-of": [
        "https://geico.com"
    ],
    "content": [
        {
            "html": "...",
            "value": "..."
        }
    ]
}

[aaronpk]

I generally support this proposal. The backwards compatibility arguments are strong. However, what happens to the product name? The simple markup will result in review-of being a URL. Would there need to be the option of review-of being a product/item? If so, what vocabulary would that use?

Compare:

                "item": [
                    {
                        "type": [
                            "h-product"
                        ],
                        "properties": {
                            "name": [
                                "Product Name"
                            ],
                            "url": [
                                "https://example.com"
                            ]
                        },
                        "value": "Product Name"
                    }
                ]

which would become

                "review-of": [
                    {
                        "type": [
                            "h-product"
                        ],
                        "properties": {
                            "name": [
                                "Product Name"
                            ],
                            "url": [
                                "https://example.com/"
                            ]
                        },
                        "value": "https://example.com/"
                    }
                ]

[rubenwardy]

I'm not sure I agree with u-review-of - what if it's a physical location or something without a canonical URL? How do you provide additional information

I feel like the p-item approach is best, just needs to be renamed to p-review-of. You can provide a h-card or h-item there, like:

<aside class="p-item h-card">
	<h3>
		<a class="p-name p-org u-url" rel="nofollow" href="https://maps.app.goo.gl/11pMKcz7auCixtPg9">BlackBörk Coffee & Caps</a>
	</h3>
	<p class="p-adr h-adr">
		<span class="p-street-address">1 Charlotte Pl</span>,
		<span class="p-locality">London</span>,		
		<data class="p-region d-none" value="London"></data>		
		<span class="p-country-name">UK</span>,
		<span class="p-postal-code">W1T 1SA</span>
	</p>
</aside>