This is the historical discussion that lead to the conclusion that A Comment is an Entry see IsaCommentAnEntry
Poll
-
A comment is an Entry
-
NickChalko, ArveBersvendsen, MichaelBernstein, RichardTallent, AsbjornUlsberg, MortenFrederiksen, DiegoDoval, JeremyGray
-
A comment is not an Entry
-
-
No opinion
-
Place your name under the option you like best. Decision will be based on TrueConsensus.
Summary
Pro:
-
Entry and comment are very similar in form. It would be architecturally efficient to make them the same.
-
Treating them the same simplifies and unifies comment, thread, and discussion models.
-
Treating them the same supports a broader view of social software
-
Con:
-
Entries are more complex than comments. To treat comments as entries will be unwieldy.
-
-1. This only requirement added to Comment is URI, which many weblogs already provide.
-
Allowing a general threading relation between entry and comment will lead to recursion, which must be limited in the spec.
-
-1. This project is about the form of Entry. For Comment to have the same form does not imply the spec must address threading or "recursion".
-
No major blogging tool supports threading today (or intends to support it in the near future) and Echo is intended to provide a well-defined, consistent specification for today's usage of the tools.
-
[RichardTallent, RefactorOk] Possible exception: SharpReader threads linked entries among subscribed feeds.
-
-1. Echo is not limited to "today's usage of the tools".
-
Echo is a format intended for weblogs, not targeting the broader view of social software.
-
-1. Echo is not limited to weblogs. See UseCases.
-
Discussion
Examples:
-
The discussion system my (KenMacLeod) company uses in-house allows both rich content (edited on the web), plain text (sent in by email), and attachments. There is an RSS feed. Logically, it's organized as a "head topic" and "messages." In many cases, the messages are as complex as the head topic.
-
There's a graphical weblog (can't find link right now) that allows people to paste graphics as comments.
[NickChalko, RefactorOk] we need a CommentEntryExample.
[NickChalko, ArveBersvendsen, AsbjornUlsberg, RefactorOk] I think making a comment an entry greatly simplifies the model.
[TomasJogin, LeonardoHerrera, RefactorOk] I think making a comment an entry greatly complicates the model.
[KenMacLeod, RefactorOk] Tomas, Leonardo, not that I disagree, but what makes you say that?
For myself, I see comments, entries, categories, feeds, sites, photo albums, playlists, blogrolls, sections, stories, archives, contact-info/about, etc. all as "resources", as meant in UniformResourceIdentifier, each that can be described with metadata. Since most of those are "content", and Entry models "content plus some metadata", I think people are leaning towards making them all "Entries". But that's just how I look at it
[TomasJogin] Isn't it obvious? An entry is a far more complex entity than a comment is, an entry has/can have authors (one or more, with contributors?) comprised of name, surname, aliasname, homepage, email, weblog, PHP-key; requires a permalink and a unique id; has a publication date and a last-modified date; has one or more (semantically equivalent) content items with MIME-types; etc and so forth. All of this is malleable of course, since the Echo (or whatever it's name) format isn't set in stone yet. Like I said, making a comment an entry would greatly complicate the model as a comment warrants a far less complex structure.
-
An entry may be more complex, but a comment can just be a minimal entry = date+author+permalink+content. Or, a comment may be complex ....
-
An entry is often also less complex than a minimal entry.
[ArveBersvendsen] A comment may have exactly the same characteristics as an entry: author, names, dates, homepage, email, content. Within the scope of the originating CMS it usually also requires an id, it probably has a last-modified.
However, instead of arguing about that, I'd suggest taking a look at Mark Pilgrim's recent comment feed.
The only conceptual difference I see between an entry and a comment, is that a comment has a well defined parent resource, be it another comment in a threaded discussion, or a blog entry.
-
Yes, and those differences are external to the entry/comment. It's more economical to use a full entry where a comment is used, vice versa. To make comment a different type of object would needlessly complicate the design.
-
[ArveBersvendsen, RefactorOk] Agreed.
[TomasJogin] Sure, a comment can be as complex as an entry, but rarely is.
-
[ArveBersvendsen, RefactorOk] My point is that a comment at the very least is a subset of a full, rich entry, and so it should be treated as an entry.
[JoeGregorio] It is very useful to conflate the concepts of entry and comment. I have folded together an RSS Item with the concept of a TrackBack, ping-back, and a comment to come up with the CommentApi, a uniform interface for commenting, which has a number of implementations.
(From a comment at Related) A Comment is an Entry - maybe scaled down in practice, maybe constrained by the hosting log, but essentially the same type. It should be treated as a peer to an Entry. For example it should have a permanent link.
A Comment can be treated as a minimal Entry without complication. The only thing added is the permalink, which would obviously be nice for referring to comments. More importantly the permalink provides a standard way to handle comments, discussions, and threads.
[GrantCarpenter, RefactorOk] I agree that there are natural benefits from having a comment and other related/feedback items be well-formed entries. What happens with permalink and post-id at the client side though? Or are we only talking about once a comment has been posted to the source (prior to that, as an API entry it's without permalink/post-id. If not, this seems to be heading towards thinking about the API itself--ideally, I would think that comments coming in via the API are wfe's but that seems unlikely if we're requiring post-id and permalink as part of a valid entry.
-
To post Entry or Comment the application will assign the permalink and post-id. Either the caller will leave those fields blank, or fill them based on calls to utilities.
[DannyAyers RefactorOk] As I see it the only real difference between a comment and a regular entry is that a comment is usually in response to another entry. This would be an issue in the Related area, perhaps not one for this project at all, but (btw) definitely in the scope of ThreadsML. How rich the comment is another matter - it *could* be as rich as any other entry.
[RogerBenningfield RefactorOk] Within JournURL, comments and entries are only distinguished by the fact that the latter has a "publish" flag set. I can comment on another JournURL user's entry, set the flag, and my comment shows up in my blog as an entry unto itself. Trackbacks, on the other hand, are kept in a sandbox because they're not authenticated.
[AsbjornUlsberg] An entry is a rich comment, without a "parent". That's the difference we have to take into consideration. The thing we have to solve now, is how to make an entry (as a commment, or something else) point to another. We have to alternatives; Either, we can make the structure flat and refer parents by id: (This will be affected by decisions about Related)
<?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://purl.org/echo/" version="1.0" xml:lang="en-us"> <title>Flat feed style</title> <entry id="e45"> <title>Parent entry</title> <content mode="xml">Yea!</content> </entry> <entry id="e48" parent="e45"> <title>Child entry (aka comment)</title> <content mode="xml">No!</content> </entry> <entry id="e733" mode="xml" src="http://example.com/weblog/733.html /> <entry id="e876" parent="e733"> <title>Yet another child entry (aka comment)</title> <content mode="xml">I agree</content> </entry> </feed>
or we can make it as a tree:
<?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://purl.org/echo/" version="1.0" xml:lang="en-us"> <title>Nested feed style</title> <entry id="e45"> <title>Parent entry</title> <content mode="xml">Yea!</content> <entry id="e48"> <title>Child entry (aka comment)</title> <content mode="xml">No!</content> </entry> </entry> <entry id="e733" mode="xml" src="http://example.com/weblog/733.html> <entry id="e876"> <title>Yet another child entry (aka comment)</title> <content mode="xml">I agree</content> </entry> </entry> </feed>
Personally, I like the flat style best, but we have do decide what to call the parent-attribute, and how to define the relation between them. Also I think this same method should be used for content-relations; if we are going to have such.
[DiegoDoval RefactorOk] In abstract terms treating a comment as an entry sounds reasonable. The problem I see with it, though, is that a comment depends on the entry to exist (Trackbacks are a different matter). The best way to make that relation implicit is through inclusion. But if comments are entries, and comments can be sub-elements of entries, then we'd go into recursion, and threads (which is where Danny's comment above comes in I think). But comments in weblogs are not threads, they are just comments, and we'd be going overboard I think if we try to go that way for 1.0. If threading is not supported, and comments are entries, we would have to artificially limit the recursion to one in the spec. But in that case it's better to call a comment a comment and not an entry.
The question is then, To thread or not to thread. We need to define this before we go on, I think. Should we have a poll for this?
In summary:
-
If we support threading, I think comments should be entries. [AsbjornUlsberg]
-
If we don't support threading, comments should be entities on their own (looking very much like simplified entries) to make clear (semantically) what they are.
[RichardTallent, RefactorOk] Counterpoints:
-
Comments by a user on his own publishing mechanism (e.g., an entry on my blog about one on yours) should not be considered any different than public responses published through some mechanism of the original (e.g., a "comments" feature). This is a current limitation of blogs: if I post a response, I usually have to post a comment to point to my site, and even blogs with TrackBack / PingBack functionality often place those links in a less prominent location and must use excerpts vs. just referencing to the original.
-
If a goal is simple tool development, surely having one class (entry) with a restricted subclass (comment) is preferable to side-by-side implementations. Both may need to be tied into HTML renderers and editors and other complex code, it makes sense to treat them as equals.
-
Hierarchal threads are evil.
-
A goal of many technologies that will be enabled by FormerlyKnownAsEcho will be social software. Artificial distinctions between the importance of "original thought" and "mere replies and comments" should be eschewed for a more collaborative, holistic view of content publishing. Not quite to the point of merging everything into a single page (*ahem*wiki*cough*), of course.
-
Yes, one artificial reason for separate entry and comment is that entries are posted by the "owner" and comments are posted by "other".
-
Use-case: publication of "forums" like PHPforum. Non-threaded, but contain discussions that are made up of collections of entries. Someone starts the conversation, others join in. The original poster is a peer of the responders.
[AsbjornUlsberg] I've put in an reference-alternative in the above examples to show how it could be if the parent don't exist inline. I've also trimmed the examples a bit so the points show clearer.
[ZhangYining] I've changed the title in second example to Nested Feed Style from Flat Feed Style.
[AsbjornUlsberg] I don't remember how it was before, but it looks fine now.
AdamRice This may not be the right place for this, but it was this discussion that got me thinking about it, so here goes. It struck me that, in a blog, the comments associated with an entry constitute a sort of feed of their own, logically speaking. Generalizing from there, I came up with this:
-
A comment is an entry.
-
An entry can contain a feed.
I readily concede there are potential problems with that, in pragmatic and philosophical terms, but a recursive structure has a certain elegance in this case. It gives an easy structure for threaded comments. It also blows open other weird but potentially useful ideas, like a blog with an outline structure, or blog entries that are subsidiary to comments. Note that this does not require a threaded structure.
Another reason a comment is an entry: Architecture of the WWW states a Principle: Use URIs - All important resources SHOULD be identified by a URI. If comments are an important resource then they will have URIs. If they have URIs then they have the same form as a minimal entry. So the question becomes: Are comments an important resource, one that multiple people will refer to? The answer is obviously Yes.
[KellanElliottMcCrea RefactorOk] We seem to be largely agreed that a comment is a form of entry.
The next step is to improve upon the semantics in the CommentApi and behaviour you see in Mark, Phil, and Sam's comment feeds (singled out because they have *good* feeds) by requiring that the relationship between comment and entry be an explicit child-to-parent linking, and not implicitly encoded somehow in the feed ordering. [See Sam's Exposing RSS Comments for related discussion]
Also, commenting is only one action in a set of related annotation behaviours. Another might be posting a spelling correct or fact checked version. Or adding some sort of meta-data. A trackback is part of this same set of behaviours.
It seem a syntax that allows all of these related behaviours to be expressed would be ideal. An example (which borrows from AsbjornUlsberg earlier example)
<?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://purl.org/echo/" version="1.0" xml:lang="en-us"> <title>Flat feed style</title> <entry id="e45"> <title>Parent entry</title> <content mode="xml">Yea!</content> </entry> <entry id="e48"> <annotate source="e45" rel="comment" /> <title>Child entry (aka comment)</title> <content mode="xml">No!</content> </entry> </feed>
I'm not sure if "source" is the best attribute for pointing back to the original, I tend to think of the syntax in terms of "about" and "resource". "rel" is short for relationship, and is borrowed from the HTML link tag.
Finally, toolkit parsing this feed wouldn't necessarily have to even know or understand the various types of relationships, but could collate them in an agnostic fashion, just like many blogs now display comments and trackbacks inline together.
-
[AsbjornUlsberg] +1 I love it. The name of the "source" attribute is a bit fuzzy for me too, as it can be "about", "resource", "source", "parent" etc. I also like the flat structure best, as it allows agreggators to ignore the relations, as you mention.
[ZhangYining] One maybe-very-silly question: Since we have,
-
An entry can have TrackBack
-
A comment is an entry
-
from 1 and 2, a comment can have Trackback, too. Yes/No?
And a Trackback can have comments, too. Yes/No? How do we capture these in EchoFeed? Or did I miss out something here?
[MarcusCampbell] !Echo will definitely have to take account of threading if it wants to remain useful in future without many changes. I only say this because some weblogs already have threaded commenting up and running. I run the BlogBack commenting system, and came up with the Comment Archive and Interchange Format specification with help from a few others (including other remote commenting system providers). Although the latest version is 0.4, version 0.2 is most widely implemented, and it remains a non-threaded format (although that is the direction it is taking). I thought mentioning it here could give a better picture of what some of us running these remote commenting systems might need for interop.
[DiegoDoval] I disagree.
Before I begin, I'd like to quote from this page in Tim Bray's weblog: "What the Echo-that-was project should be about is picking the stuff that’s already been proven to work and be interoperable, and writing it down in a clean, clear way, and arranging for the specification to be clearly out of the clutches of any vendor."
-
That is Tim's opinion, not the consensus of the Echo project.
On to my argument. I understand the rationale for threading but I can't agree with the end result that easily: Zhan's comment is a good example of the issues that threading opens up.
My biggest concern is that we would be designing something without prior art, without experience. In making comments entries, we are not trying to solve a particular problem, we are imagining potential future applications but we don't have a variety (Note: variety) of real world examples to guide us. In my experience, this leads to over-design and almost certainly we will make the spec more complex than necessary. According to the RoadMap, Echo 1.0 should be well-defined and extensible. I think future applications should use the extensibility mechanism, and eventually new practices codified in Echo 2.0. Comments-as-entries would also affect other parts of the spec that at this point are more evolved, in particular the definition of an entry itself. If you look at Sam's Echo feed snapshot for july 1 you'll see that the feed does not look like the feed example with comment/entry gave above by Kellan. Kellan used attributed to the entry tag to add the source. Since attributes use has been limited in the EchoExample and elsewhere, then adding the parent/child relationship would probably need the addition of an attribute.
-
The point is not to use the above syntax exactly as it is written. The point is that it would be mistake to move forward with comments being entries without requiring that they state their relationship to the entry they comment on explicitly in a child to parent fashion. (which has quite a bit of prior art supporting it) [KellanElliottMcCrea]
Kellan also said at the end of his comment "Finally, toolkits parsing this feed wouldn't necessarily have to even know or understand the various types of relationships, but could collate them in an agnostic fashion, just like many blogs now display comments and trackbacks inline together." I would hope that if we add a feature to the Echo core, it is precisely so that toolkits or tools that use the feed or APIs deal with the data and use it, not ignore it and display it in some innapropriate way (if the discussion is threaded, displaying it in non-threaded fashion sounds nearly catastrophic to me). Otherwise it's prime material for an extension.
-
It has long been standard practice in RSS parsing to ignore what you don't understand. Encouraging this behaviour as it relates to defining types of relationships allows for future evolution. [KellanElliottMcCrea]
Another example, a discussion has started with trackbacks, in IsaTrackbackAnEntry and if trackbacks are entries, and comments are entries, then you could theoretically have a threaded sequence of comments to trackbacks and trackbacks to comments, which, while cool-sounding, feels pretty complicated to me to be grasped by users at this point and would be a difficult to render intelligibly in an HTML page and allow easy user interaction (the first output of Echo is HTML--then comes the rest). What would a page that allows threaded comments and has those mixed with trackbacks look like in, say, movabletype or blogger today? I can't see it. And that's a good reason for me to think it's not the right time for this yet.
Conclusions: There are no good UIs for this. There are no major use-cases that we can use as examples (although there could be many future applications), we'd be only going on our instinct to generalize constructs just because we can. I think it's better to leave this for use by Echo extensions.
I know I might be the only holdout at this point, I'm willing to be convinced though :). So, I have two specific questions:
-
First, I'd like to see a clear definition of comment-as-an-entry that explains how the issues with recursion are handled, and if today comments are displayed, how is the display handled? how is the editing handled? I only mean rough outlines of how this issues would be handled.
-
Second, and perhaps more important, I'd like to see some examples of usage of this feature. I don't mean applications, but actual examples of usage by real users, people that are actively managing weblogs where threaded discussion takes place (To look at what are they doing today).
-
[RogerBenningfield] Actual users:
-
If comments become recursive (or circular), the consuming end can/should be aware and takes care (fair?).
-
Examples of nested comments that I can think of is SlashDot. And another usages could be that BBS forums or mailing lists can/might provide the dicussions as EchoFeed (useful? not sure at the moment).
I tend to agree both Comments and TrackBacks are entries, the problem is their responsiblity in the conceptual model to be ironed out so implementations(and migration) can move on.
Folks working on RSS readers and aggregators can share their concerns on this?
[DiegoDoval RefactorOk] Zhang, part of the software I work on contains an RSS aggregator, and your question is one of the reasons why I made that long comment before.
[ZhangYining RefactorOk] Diego, I share the same concerns as you, and the reasons I mentioned are exactly why I am not going to write an aggregator myself Now let's summarize a litte from the above dicussion by further clarifying the following:
-
Is a comment a resource (see Adam's opinion above)? i.e. Do comments deserve URI's of their own?
[AdamRice] Point of clarification: I did not write the paragraph about URIs you refer to--someone else appended it after my comment without identifying himself. But I agree with it.
[AsbjornUlsberg, RefactorOk] Yes and yes.
-
How much commanality do a typical original entry and a comment have? title, content, author, published date, etc. Is it better to have a higher abstraction to derive both from or to have independent defintion of their own?
[AsbjornUlsberg, RefactorOk] Entries and comments share a lot, and will share more in the future. The question is wether it's necessary to have a <comment> element or not, and when it comes to extensibility and simplicity, having a lot of elements restrains and complicates things. Sharing elements for many uses (and specializing the elements with attributes, if needed) is the best thing to do, because then we will have a neat, well-structured and object oriented model.
-
There are already threaded (read nested) commenting weblogs (e.g. Slashdot, OReilly, but comments are not part of the feed, only on HTML), for adoption of Echo, we need a way to address that in the data model level.
[AsbjornUlsberg, RefactorOk] Absolutely. A flat style would be best, as it can be supported both with and without knowing the internal relationship between the entry's.
-
Complexity in actual implemenation could be huge in cases like circular referencing (but not so in normal threaded comments, true?), so is data model the right place to address it? or the CommentApi or protocol (dare I say that!) the better place to deal with it?
[AsbjornUlsberg, RefactorOk] The data model can't solve this. It has to be done by the systems that aggregates and produces feeds, mainly by the production systems. The API (or protocol, if that's what we call the whole concept) is imho the right place to adress this, if we really are going to be the ones to adress and fix it. If not, we'll just say that "preventing circular references lies on the shoulders of Echo-implementors, and not on the Echo standard itself".
[AdamRice] Rather that referring to parent entries, nest the subsidiary entries inside them (Asbjorn's second example). Circular references become impossible, and the hierarchy is immediately apparent to anyone inspecting the code.
-
[AsbjornUlsberg, RefactorOk] With a non-flat view of the relations (with entries inside entries), the feed will be much more difficult for implementors to parse, and you *need* to understand the structure to even print out *anything*. Of course, it's easy to have a generic XSLT template that matches "entry", which is applied for every entry, but not all implementors use XSLT to display or transform their data. It should at least not be a requirement to use XSLT to get anything out of the Echo format. Instead, the structure should be flat, so that agents that has support for threading threads the entrys, and for the other, the entries are just written serially from first to last entry, possibly sorted on "post-date".
-
[AdamRice. RefactorOk] I bow to your greater knowledge. I can imagine somewhat-artificial situations that get around the problem you describe, but, well, they're artificial. Still, it seems that if there is a threaded feed, and a parser wants to present it in threaded form, then there will be more programming overhead if the feed structure is flat. Even if I'm right, it's sort of a six-of-one, half-dozen-the-other matter. Nesting strikes me as more elegant, but this is about getting things done.
-
[ZhangYining RefactorOk] If (I think yes) it is a responsibility of implementation of aggregator, let's hear what implementors would say on this (and try to convince them :-p ), acceptance and support is critical for adoption of Echo.
-
[ZhangYining RefactorOk] IIRC, that's defined in the DublinCore (sourceURL?) or some other modules (?)
[ZhangYining RefactorOk] Assuming threading is to be supported by Echo, now we have something to think of, which to use? Nested entries as in Asbjorn's example or a flat list with [Related] extension to enable threading of comments? Each has its own merits and shortcomings:
-
Nesting entries, by nature, avoids the circular referencing problem;
-
Flat list with [Related] extension eases the (initial)support effort for aggregator implementions;
Personlly I favour the latter.
-
[AdamRice, RefactorOk] Problem I see with [Related] is that the discussion there seems to be in favor of using the Xlink namespace. Well, two problems: nesting becomes dependent on an extension (how core should it be?) and Xlink is pretty complicated--might as well go back to RSS 1.0.
[DiegoDoval] Okay, I've been thinking about this and playing around with parsers, and in particular API options for comments which is one of my main concerns. I'm reasonably convinced (I do vote for the flat structure proposal though, rather than nesting entries in the syntax). As a result, I'm changing my vote. I think we should refactor this page and define something we can take back to be used directly in the EchoExample and other related pages. Adding an optional parent-id element to an entry seems to be enough to start with no? We'll also have to make sure that there are no conflicts in the assumptions regarding an entry and those necessary for a comment, and consider how trackbacks fit (see IsaTrackbackAnEntry).
[ ] Instead of an optional parent-id (basically a URI with a fixed role) Related suggests 0+ relations that include (role)+URI. That way the entry-comment relation can be handled with the same data structure as the RSS link element, etc.
[ZhangYining] Please take a look at CommentEntryExample, especially regarding referencing back to parent entry, and entry Id.