UserPreferences

IsaCommentAnEntryDiscussion


This is the historical discussion that lead to the conclusion that A Comment is an Entry see IsaCommentAnEntry

Poll

[ClosedPoll]

Place your name under the option you like best. Decision will be based on TrueConsensus.

Summary

Pro:

Con:

Discussion

Examples:

[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.

[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 [WWW]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.

[TomasJogin] Sure, a comment can be as complex as an entry, but rarely is.

[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 [WWW]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.

[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 [WWW]ThreadsML. How rich the comment is another matter - it *could* be as rich as any other entry.

[RogerBenningfield RefactorOk] Within [WWW]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)

[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:

[RichardTallent, RefactorOk] Counterpoints:

[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:

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: [WWW]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 [WWW]Mark, [WWW]Phil, and [WWW]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 [WWW]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)

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.

[ZhangYining] One maybe-very-silly question: Since we have,

  1. An entry can have TrackBack

  2. A comment is an entry

  3. 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 [WWW]BlogBack commenting system, and came up with the [WWW]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 [WWW]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."

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 [WWW]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.

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.

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:

[ZhangYining]

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. [] Regarding circularity in threads: Here the question is to compare the form of Entry and Comment - required properties of author, location, date, content. The notion of threading is in an extension: Related. Related adds the link between Entry and Comment so the actual linking and processing of Entries/Comments should be addressed there. But in both cases we are just specifying basic data structures. Issues of complexity and circularity are for the application developer to address. The Entry data structure just gives developers a common framework to wrestle with such problems. And consider: RSS defines the link element, which can refer to a permalink, circularly. This hasn't been a problem.

[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:

Personlly I favour the latter.

[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.


CategoryMetadata, CategoryModel