h-entry
h-entry copied to clipboard
Consider merging h-review properties into h-entry
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
andworst
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 suggestedu-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
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.
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.
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.
Based on the discussion at the most recent HWC Pacific, I updated my watched page to use u-review-of
as well.
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?
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.
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": "..."
}
]
}
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/"
}
]