Standardise a fallback mechanism (summary property?) for unrecognised entries?

[Zegnat]

As h-entry is getting used for more and more different types of posts (IndieWeb: PostType, SWWG: Post Type Discovery) and as a way to move those posts around (Micropub) the amount of cases where a consumer doesn’t know what to do with the entry grows.

Having a form of human-friendly description available as fallback has come up several times over the years. When a consumer does not understand a combination of properties it may rely on having a plain text alternative instead.

Not only posts using draft properties or fully experimental properties are helped by this. Even posts that only use core properties such as a like post can be hard for consumers to deal with due to a (possible) lack of content. As an example: Loqi has no special handling for likes and would use fallback properties.

Implementers of microformats consumers could be helped by us specifically calling out a property as “good to use as fallback”. The h-entry vocabulary would be a prime page to do this. Example: @manton wrote that he doesn’t want people scared by all the potential properties, I think being able to say “just make sure to implement the fallback mechanism” goes a long way there.

TL;DR: should we codify summary as a proper fallback that consumers can use when the entry contains other properties that aren’t understood? Are there special cases where this would not be optimal?

---

Long read: I tried to pull in some history, some current debates, and some iteration on fallback properties. This should give a pretty good overview of the thoughts behind the above TL;DR and this issue.

A read post implementation by @gRegorLove used the content property as an HTML fallback:

The h-cite object also has a content property which has an html key. The value of that key is the HTML for the citation. This serves as a fallback in case the site does not process the micropub h-cite object directly.

In the latest iteration of the read posts, as posted through indiebookclub, this has been dropped entirely in favour of the summary property. See microdotblog/issues#92 for details on the microformats2 JSON used for Micropub.

On that same issue, @aaronpk writes in to elaborate on why summary is a better fallback than content. Quoting in full:

The summary property is intended to be used for fallback for when the server doesn't recognize the other properties of the request. Most Micropub servers understand content and photo, but this is a great example of an interesting content type that is likely not supported by most servers yet. In this case, summary is the correct place for this fallback content. The content property would be misleading since normally the content property contains user-entered text. For example, if the user enters a note about why they wanted to read this, that could be included in the content property.

This point was also made in the IndieWeb chat:

• the functional difference between summary and `content is demonstrated by a photo post that has no caption. it would be misleading to have the client generate a summary of the photo and include that in content, since then the server would have no way of knowing whether the content was something the user entered or not

Using the summary property as fallback has been brought up several times. Including by @tantek in discussions about parsing comments:

• ... So when people started doing lieks via webmention, by including a summary in your like that says 'so and so likes this'

• ... if you understand likes you ignore the summary and just increment your counter or whatever

The Micropub standard also notes the summary property in its section on unrecognised properties:

For example, a client may create a post that contains a weight measurement, with an h-measure value for the weight property, and a plaintext summary of the post in the summary property. Servers that don't recognize the weight property will simply ignore it, and will create the post as a plaintext post with the summary instead.

The Micropub standard also calls out that unrecognised properties may just be ignored:

If the request includes properties that the server does not recognize, it MUST ignore unrecognized properties and create the post with the values that are recognized.

This may lead to unexpected consumer behaviour and is the only pain-point I can think of, as I wrote in the chat:

• I think it is hard to figure out exactly when to fall back to summary. In the photo/content/summary case, you want to ignore content and use summary if you do not support photo. But in the photo/content/summary/location case, if you do support photo but not location, you probably only want to ignore location rather than fallback to only summary :(

To stick with the photo post:

• if an entry contains photo, content, and summary properties and the consumer does not understand photo then summary should be used by itself. Using content when this relies on the photograph is unwanted.

• if an entry contains photo, content, summary, and location properties and the consumer does not understand location then… what? Ignoring location and using the photo and content properties for a bare photo post seems to make sense in some context.

This makes it hard to just say “fallback to summary when the combination of other properties is unknown”.

Also note: non of the discussions I was able to find talk about how this overlaps with the use of summary for h-entry objects within h-feed objects. Could advertising summary as universal fallback have a negative impact there?

[Zegnat]

Whelp, that got a bit long! But I hope it captured all the different thoughts and angles, centralising the entire discussion to this one issue 😄

[kevinmarks]

This makes sense, but what about name? That should be used to show the sense, with summary as a more detailed version.

By removing implied name, have we made the ability to use name as a minimal version of any post format harder?

On Sun, 10 Jun 2018, 17:16 Martijn van der Ven, notifications@github.com wrote:

Whelp, that got a bit long! But I hope it captured all the different thoughts and angles, centralising the entire discussion to this one issue 😄

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/microformats/h-entry/issues/9#issuecomment-396061402, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGCwBmG3xy7EdXdU2lnvHppo0MaM4_bks5t7UZggaJpZM4UhxlX .

[Zegnat]

By removing implied name, have we made the ability to use name as a minimal version of any post format harder?

Probably yes. Were consumers actually using name “as a minimal version of any” unrecognised post? I’m not sure. Most consumers that weighed in on the implied name issue were having problems because name was always present and it was hard to know when it was actually a usable title.

This is why I also brought up summary in the context of feeds: if summaries in that context are being used in a way that makes them hard to be used as fallback we might need a different property. Else we run into the issue we tried to solve around name where consumers have a hard time distinguishing fallbacks from e.g. small teasers used in feed context.

I think this risk might be minimal. As a properly written summary for a feed will often work well as a stand-alone fallback for the entry.

[kevinmarks]

There is demand for previewing entries in general, and I think that the name, summary, featured image combination is the pattern that is being converged on - see discussion here: https://github.com/ampproject/amphtml/issues/657

Is the distinction between fallback and teaser significant if there is a link to the full version, or is this like the problem with permalinks to notes where clicking through gives no more information?

Twitter moments have the reverse problem, where the presentation of a tweet there is often less coherent than inline, because quoted tweets are not expanded; tweets have grown richer by showing upstream and downstream threads, so clicking through can still have benefit.

Encouraging non-duplicative use of summary is a good idea.