This is where I would point to my comment in #21 - FEP-b2b8: Simplify `preview` - evanp/fep - Codeberg.org
this use of preview
muddies the waters because you canât necessarily assume that any property of the Article also apply to the preview Note.
taking the FEP at its word:
Especially for microblogging applications, the preview
property is a useful fallback for supporting unrecognized object types like Article [âŠ] For an article, the preview can be a Note that gives a well-formatted preview of the article content in its content property. For example, the name
, summary
, and a link to the url
would be an appropriate representation.
if this is an appropriate representation to just take name
summary
and url
, then why not just do that directly? i mean, we already have a âuseful fallbackâ described in AS2-Core: using the name
and summary
! Activity Streams 2.0
i understand that there is a tension between publishers wanting to be accurate and publish Article
objects vs. consumers special-casing Article
objects and using fallback representations for them, but i donât see how preview
helps here â youâd still be special-casing.
what is really going on here is that you are dealing with a desire for multiple representations of the same resource, but you are forced to stuff it all into a single HTTP resource. so you are not really asking for a âpreviewâ, you are asking for an âalternate representationâ. rel=alternate
, not rel=preview
.
Matthias Pfefferle also raised this concern:
If we treat the preview Note as a standalone object that can be used as-is, weâd also need to include the context, replies, reposts, likes collections, audiences, and more. From my perspective, itâs impossible to ignore the surrounding object.
You canât just treat the preview
as âthe same objectâ and assume that any properties of the Article will also apply to the Note. They are separate objects, always.
The more idiomatic way to have an object be represented or interpreted in multiple ways is to use specific vocabularies and classes as appropriate. For example, instead of quibbling about the difference between Note
and Article
, you could capture the semantics of a âpostâ which is what you really care about:
{
"@id": "#something"
"@type": [
"https://www.w3.org/ns/activitystreams#Note",
"http://rdfs.org/sioc/ns#Post",
"http://joinmastodon.org/ns#Status"
]
}
Here, we are making the claim that #something
is simultaneously a âNoteâ, âPostâ, and âStatusâ.
The core of the UX issue is that Note is overloaded to mean âMastodon-style statusâ instead of actually defining an unambiguous class to represent the set of all things that can be considered Mastodon-style statuses.
You might think that itâs bad for interop if everyone defines their own classes for everything, but thatâs not what Iâm saying. What Iâm saying is that reusing or overloading a class is also bad for interop, probably even worse. Think of types and classes as a sort of interface that can be fulfilled â if the interface is fulfilled, the current object/thing belongs to the class or set representing all things that fulfill the interface. You should reuse classes that already exist, but only if the semantics match EXACTLY. If the semantics arenât an exact match, then you have introduced ambiguity.
We might say that for a âPostâ, what we really care about is the âcontentâ, plus some other supporting properties. This is the level at which âsocial media postâ use cases should operate. In some ways, the AS2 content model is a bad fit for those use cases, because the AS2 content model is very heavily oriented toward Activities rather than Posts. The problems of âlongform textâ are largely artificial.