fLaMEd, eitilt1 and [davidmead] joined the channel
#[davidmead]Back in 2016 I used to PESOS checkins from Untappd to my blog (https://indieweb.org/Untappd), but that’s gone the way of the Dodo. I’m going to add them back to my blog, but what do others, if any, mark them up as? h-review? h-event? both?
#[KevinMarks]h-review is what they primarily are I would think, though some are also events and possibly check-ins.
gRegorLove_ joined the channel
#[davidmead]I know. It’s a bit of a mixed bag. If I drank it in a venue, I’d have to mark that up too. I’ll play around, see what I come up with
#[davidmead]I don’t recall them ever being marked up with microformats in the past
#[KevinMarks]the Untappd structure potentially has 2 venues for where it was consumed and where it was bought if that's different.
eitilt, eitilt1, gRegorLove_, gRegorLove__, [Paul_Robert_Ll], barnaby and [jeremycherfas] joined the channel
#aaronpkThat matches my own review publishing practices
#aaronpkits a blog post with a few extra properties
#barnabymakes sense for consumers, too. if you publish reviews as .h-entry.h-review, then anything which can handle h-entry will show most of the content just fine, and anything which wants to add additional features can do so without having to implement handling a whole separate type of post
[manton], [schmarty], nsmsn and [aciccarello] joined the channel
#[aciccarello]I like the double h-* idea. Not sure if that would confuse any parsers though.
#[aciccarello]I've had to add some special case logic for my h-reviews
#barnabyit shouldn’t confuse any parsers, the item just ends up with "type": ["h-entry", "h-review"]
#barnabyin jf2 “Type MUST be a single string value only.”
#barnabyare there any know jf2 consumers which handle reviews? If not, I’d err towards publishing jf2 .h-entry.h-review as type: entry with additional properties
#[tantek]barnaby, add the issue on h-entry, something like (feel to reword) : consider merging h-review functionality / particular properties into h-entry
#[tantek]aaronpk, re: "suspect h-review was a holdover from the mf1->mf2 migration", correct, based on the usage/publishing/consuming of classic mf1 hReview
#tantekedited /hreview (-5) "editorial: microformats IRC channel, regardless of how its accessed, previously mailing list which hasn't been used in years." (view diff)
#[tantek]part of the problem with publishing reviews, as Google found it, is that its a massive spam magnet
#[tantek]gRegor, in hindsight, I think h-review-aggregate was also not a great idea as it was mixing publishing and aggregating
#[tantek]the mf1 predecessor, hReview-aggregate, came out of early collaborations with the structured data folks at Google, who were very focused on "simple" publisher / search engine indexing use-cases
#[tantek]and in hindsight, we now know that the "search engine indexing" use-case is a very poor use-case to use to design technologies because it's a giant spam magnet
#[tantek]that is, technology designed for that particular use-case will result in another spammy information vector
#Loqi[preview] [barnabywalters] #32 Consider merging h-review properties into h-entry
#barnaby(also worth mentioning that I don’t have strong opinions about this either way and am not personally invested in it as I have no plans to publish h-review, just wanted to summarize discussion somewhere while it’s in my head)