FEP-b2b8: Long-form Text
-
Hello!
This is a discussion thread for the proposed FEP-b2b8: Long-form Text.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.
SummaryMulti-paragraph text is an important content type on the Social Web. This FEP defines best practices for representing and using properties of a long-form text object in Activity Streams 2.0.
cc @eprodrom
-
Hello!
This is a discussion thread for the proposed FEP-b2b8: Long-form Text.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.
SummaryMulti-paragraph text is an important content type on the Social Web. This FEP defines best practices for representing and using properties of a long-form text object in Activity Streams 2.0.
cc @eprodrom
I am happy to mention that @thebaer of #software:writefreely has a pull request available that, when merged, will make Writefreely eligible to be mentioned in the "Implementations" section (see FEP document sections for more info). The announcement was made in this toot just now.
-
I am happy to mention that @thebaer of #software:writefreely has a pull request available that, when merged, will make Writefreely eligible to be mentioned in the "Implementations" section (see FEP document sections for more info). The announcement was made in this toot just now.
I will have to review the FEP for any recent changes, but NodeBB is also compatible with this FEP.
-
Hello!
This is a discussion thread for the proposed FEP-b2b8: Long-form Text.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.
SummaryMulti-paragraph text is an important content type on the Social Web. This FEP defines best practices for representing and using properties of a long-form text object in Activity Streams 2.0.
cc @eprodrom
Personally I find the distinction between the
Note,Document,ArticleandPagetypes in the Activity Vocabulary entirely arbitrary and they ought to all just be the same type.I would rather suggest that implementations should consider all of these types to be completely equivalent to each other. If an implementation wants to differentiate how they present short-form and long-form text, then simply check the length of the content and act accordingly - don't rely on the arbitrary type field to tell you whether something is "long" or "short", whatever that means.
The actual length of the content should be the source of truth about whether something is long-form or short-form (according to whatever definition of short and long you want to use). The type field is not the source of truth of this information.
There is nothing preventing an implementation from sending a
Notewith 10 paragraphs or even 1000 paragraphs, so any implementation that hopes to handle such a thing would need to include checks for the length anyway - so again, it is much simpler and easier to just consider all these arbitrary types equivalent and let the actual length of the content decide how to present it. -
Hello!
This is a discussion thread for the proposed FEP-b2b8: Long-form Text.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.
SummaryMulti-paragraph text is an important content type on the Social Web. This FEP defines best practices for representing and using properties of a long-form text object in Activity Streams 2.0.
cc @eprodrom
SorteKanin:Personally I find the distinction between the
Note,Document,ArticleandPagetypes in the Activity Vocabulary entirely arbitrary and they ought to all just be the same type.They are only arbitrary when we don't assign distinctive semantic meaning to them. Here are the meanings as described in ActivityStreams. I looked up at schema.org for equivalents and put this in for comparison..
| ActivityStreams | schema.org || :--- | :--- ||
Article: Represents any kind of multi-paragraph written work. |Article: An article, such as a news article or piece of investigative report. Newspapers and magazines have articles of many different types and this is intended to cover them all.|Document: Represents a document of any kind. |DigitalDocument: An electronic file or document.|Note: Represents a short written work typically less than a single paragraph in length. |Statement: A statement about something, for example a fun or interesting fact.|Page: Represents a Web Page. |WebPage: A web page.My observation is that the type definition and intended purpose should be further clarified. In the comparison to schema.org you see that an
Articleis usually some piece of text that is published to an audience. Whereas aNoteis a brief statement, a notification status (some apps use the term 'statuses').Pageis confusing until you know it means web page.These types convey semantically meaningful information. A
SorteKanin:Documentisn't necessarily also anArticlethat can be published. ANoteis what a library may present you on theirPageto tell you aDocumentis unavailable. Etcetera.There is nothing preventing an implementation from sending a
Notewith 10 paragraphs or even 1000 paragraphsThis is still no reason to throw the extra semantic context overboard. "Different type, different business logic" - should there be a need for that wrt increasing interoperability - is much easier to deal with than implicit rules. We see already that the urge of many developers who only deal in Notes, is to add extra properties to them to indicate special behaviors, instead of typing them properly as linked data intents.
-
SorteKanin:
Personally I find the distinction between the
Note,Document,ArticleandPagetypes in the Activity Vocabulary entirely arbitrary and they ought to all just be the same type.They are only arbitrary when we don't assign distinctive semantic meaning to them. Here are the meanings as described in ActivityStreams. I looked up at schema.org for equivalents and put this in for comparison..
| ActivityStreams | schema.org || :--- | :--- ||
Article: Represents any kind of multi-paragraph written work. |Article: An article, such as a news article or piece of investigative report. Newspapers and magazines have articles of many different types and this is intended to cover them all.|Document: Represents a document of any kind. |DigitalDocument: An electronic file or document.|Note: Represents a short written work typically less than a single paragraph in length. |Statement: A statement about something, for example a fun or interesting fact.|Page: Represents a Web Page. |WebPage: A web page.My observation is that the type definition and intended purpose should be further clarified. In the comparison to schema.org you see that an
Articleis usually some piece of text that is published to an audience. Whereas aNoteis a brief statement, a notification status (some apps use the term 'statuses').Pageis confusing until you know it means web page.These types convey semantically meaningful information. A
SorteKanin:Documentisn't necessarily also anArticlethat can be published. ANoteis what a library may present you on theirPageto tell you aDocumentis unavailable. Etcetera.There is nothing preventing an implementation from sending a
Notewith 10 paragraphs or even 1000 paragraphsThis is still no reason to throw the extra semantic context overboard. "Different type, different business logic" - should there be a need for that wrt increasing interoperability - is much easier to deal with than implicit rules. We see already that the urge of many developers who only deal in Notes, is to add extra properties to them to indicate special behaviors, instead of typing them properly as linked data intents.
aschrijver:They are only arbitrary when we don’t assign distinctive semantic meaning to them.
But is there any meaningful semantic difference?
- ActivityStreams says Article is just a multi-paragraph written work. Schema.org says it is specifically for news articles, but that's clearly not what this FEP is suggesting (and doesn't make sense with ActivityStreams' definition).
- Document is literally a tautology and is completely meaningless (the definition may as well have been "A document is a document").
- A Note's only distinguishing characteristic seems to be that it is short (schema.org's
Statementis not at all howNotes are currently used on the fediverse and is clearly not what this FEP is suggesting). Pageis currently used by Lemmy for all posts in communities. Page also inherits from Document, which is sort of confusing (aren't pages usually part of a document, not the other way around?). And what is a web page other than HTML? But all of these things are essentially just HTML.
My point is that these things are so tenuously defined that it becomes vacuous. They all just boil down to HTML, or less technically, what most people associate with any general "post" on social media (at least those that aren't restricted to short-form content).
In addition, these definitions aren't fitting how these types are used on the fediverse at all. For instance, comments on Lemmy are currently
Notes but have no length restriction.EDIT: Even this post itself is posted on ActivityPub as a
Note, despite having many paragraphs.The only actual meaningful distinction between these types seem to be their length, with an arbitrary distinction between single-paragraph and multi-paragraph. But we don't need a standard to tell each implementation where to put the border between "short-form" and "long-form." Each implementation, or even each client, can easily choose by itself what they consider to be "short-form" and "long-form" by simply checking the length themselves.
-
aschrijver:
They are only arbitrary when we don’t assign distinctive semantic meaning to them.
But is there any meaningful semantic difference?
- ActivityStreams says Article is just a multi-paragraph written work. Schema.org says it is specifically for news articles, but that's clearly not what this FEP is suggesting (and doesn't make sense with ActivityStreams' definition).
- Document is literally a tautology and is completely meaningless (the definition may as well have been "A document is a document").
- A Note's only distinguishing characteristic seems to be that it is short (schema.org's
Statementis not at all howNotes are currently used on the fediverse and is clearly not what this FEP is suggesting). Pageis currently used by Lemmy for all posts in communities. Page also inherits from Document, which is sort of confusing (aren't pages usually part of a document, not the other way around?). And what is a web page other than HTML? But all of these things are essentially just HTML.
My point is that these things are so tenuously defined that it becomes vacuous. They all just boil down to HTML, or less technically, what most people associate with any general "post" on social media (at least those that aren't restricted to short-form content).
In addition, these definitions aren't fitting how these types are used on the fediverse at all. For instance, comments on Lemmy are currently
Notes but have no length restriction.EDIT: Even this post itself is posted on ActivityPub as a
Note, despite having many paragraphs.The only actual meaningful distinction between these types seem to be their length, with an arbitrary distinction between single-paragraph and multi-paragraph. But we don't need a standard to tell each implementation where to put the border between "short-form" and "long-form." Each implementation, or even each client, can easily choose by itself what they consider to be "short-form" and "long-form" by simply checking the length themselves.
No, there's not much meaningful semantic difference even in the wild. Granted, use of non-
Notetypes is still rather limited currently, but we can draw some expectations (which come with a hefty dose of exceptions):- A
Noteis shorter than anArticle(unless it is not), and vice versa (unless it is not) - An
Articlecontains inline images (unless there aren't any) Notes tend to contain attachments (unless there aren't any)
... I could go on, but everything I'd say would come with "(unless..)" alongside it.
I think what evan@cosocial.ca is attempting to do with the FEP is assign some suggestions as to how to classify content, and suggesting that there could be display differences on the implementor side for each individual type (unless there aren't any differences ha ha ha)
> Personally I find the distinction between the
Note,Document,ArticleandPagetypes in the Activity Vocabulary entirely arbitrary and they ought to all just be the same type.The problem here is that
Noteis now loaded with expectations so as to become highly-specific. You can't use inline images, you must cap attachments at 4, you may have to re-order attachments, etc. -
@julian those four types are very different.
-
julian:
The problem here is that
Noteis now loaded with expectations so as to become highly-specific. You can't use inline images, you must cap attachments at 4, you may have to re-order attachments, etc.Says who? I don't see any such requirements in the spec. In Lemmy I can put as many images in a comment as a want. Here on Discourse I don't think there is a limit on any of these things either?
But again, if any implementation wants to handle content differently (like short or long form content, or content with lots of images, or whatever), then that's that implementation's imperative and you can't use these types to enforce anything anyway.
Handling all manner of arbitrary requirements from different implementations would also be way too complicated. Implementations should rather try to handle as broad a set of content as possible and display it in an appropriate way.
-
julian:
The problem here is that
Noteis now loaded with expectations so as to become highly-specific. You can't use inline images, you must cap attachments at 4, you may have to re-order attachments, etc.Says who? I don't see any such requirements in the spec. In Lemmy I can put as many images in a comment as a want. Here on Discourse I don't think there is a limit on any of these things either?
But again, if any implementation wants to handle content differently (like short or long form content, or content with lots of images, or whatever), then that's that implementation's imperative and you can't use these types to enforce anything anyway.
Handling all manner of arbitrary requirements from different implementations would also be way too complicated. Implementations should rather try to handle as broad a set of content as possible and display it in an appropriate way.
Says Mastodon, implicitly, because those are the restrictions you have to follow if you want your content adequately represented on there.
You can say it doesn't matter what Mastodon says, and you're right, but my users don't care about that, they just want their content displayed on Mastodon properly.
