UserPreferences

RelatedDiscussion


Refactoring in progress
Please take new discussion, and summaries from here, to Related

Proposal

Implement Related as

relationTitle, relationRole, and relationLocator as defined in the [WWW]XLink or [WWW]HLink specs.

relationAuthor defined the same as echo:author

Pro

Con

Sample Code

see CommentEntryExample, Related

Discussion

Relations can be classifed to represent the various types of objects in the environment. To explore design cases, it is useful to consider three distinct types of object:

See GeneralizingEntry and Containers for broader design issues.


The proposal requires a role URI that points to the relation types defined by Echo. Is there an existing vocabulary like this?

Yes : [WWW]ThreadsVocabulary

[DannyAyers] I believe it would make a lot more sense to create a robust SyntaxExtensionMechanism for Atom, to allow vocabularies like this (and topics, and FOAF and reviews...) to be used as required.


Reciprocal relations may be established through some handshake mechanism conceptually similar to Trackback.

Related implies an API to post a relation. The problem is that this can become a source of spam. An entry must be able to reject unwanted links. The posted relation also needs an "author" who can be verified as in Identity.

API prior art


It seems likely that Entries will have a permalink and a unique identifier (PermaLinks, PostIdSpec, EntryIdentifier). In some cases (when the relation points to an Entry in another weblog) the relationLocator should be the permalink. In other cases (when one entry points to another within a feed) the relationLocator may need to be the unique indentifier. Is this a source of confusion?

Related can be a lot like Entry: required elements author+date+permalink, but not content. Instead of content, it has role. In other words Related points to another Entry/resource instead of including its content.


I think the description of Relation needs sharpening, but aside from that I think this could work with other systems such as ThreadsML [RefactorOk DannyAyers]

Discussion elsewhere

EchoFeedWithAuthorRefs about expanding Related to author information. (also proposed page ReferenceMechanismDiscussion

SyntaxExtensionMechanism

content-by-reference discussion: ContentDiscussion, EntryContentDiscussion

"a complete list of outgoing links would make for a great (not-)Echo extension module..." [WWW]diveintomark

TimBray [WWW]suggests that Related-like functionality can be included in the XML content. Then later, working techniques could be migrated to separate elements if needed.

PhilWolff on [WWW]Echo and semantic blogging.

Early Discussion

Related supersedes and includes


For this high-level design of a WellFormedEntry, the concepts of Entry, Comment, Thread and Dialog may be due for a refactoring.

First, 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.

Second, Entries often have implicit relations to other Entries embedded as links in the content. Likewise a Comment has an implicit relation to an Entry. These would be expressed in RelatedExtension along with explicit typed relations of Entries required for Dialog and Thread.

RelatedExtension could thus subsume CommentExtension, ThreadingExtension and DialogMappingExtension.

Note - ThreadsML aims to provide direct support for ThreadingExtension and through the subsumption CommentExtension, with DialogMappingExtension available to apply as a specialization using the IBIS vocabulary.

A first approximation for all these applications would be to use a single type of relation, call it "cites". Near-synonyms include "in reply to", "references", "influences", "informs" and "is related to". All of these have a reciprocal such as "is cited by". "Cites" is nice because its root in Latin means "set in motion". By citing we set in motion an entry that would otherwise be, in effect, sediment.

The author of Entry C would indicate the influences as s/he writes

(Let's drop the parent/child metaphor in favor of this more neutral relation. Parent/child is misleading because on one hand it suggests a simple relation - parent precedes child in time. But this may not hold. Initially the times of Entry A and B would be earlier than Entry C, but the author could edit to include a later pertinent Entry D. On the other hand parent/child suggests the hierarchy of generations, a concept which isn't needed.)

This modelling has been discussed previously on the [WWW]ThreadsML QuickTopic - some apposite notes can be found at [WWW]Parent-Child Modelling -- DannyAyers (2003-06-23 added comment on remote page regarding timeline)

Just this would do a lot to reconcile Comments and Threads. Dialog requires other types of relations between Entries, but the data model is the same.

[DiegoDoval, RefactorOk] I think that comments need some sort of parent/child relationship. A set of comments attached to an entry disappear when the entry is deleted. Reconciling the ideas of comments and threads is an interesting goal, but I think it goes beyond the scope of Echo 1.0 (since it's a new generalization, rather than a concept used by weblog tools today)

[RichardTallent, RefactorOk] (This is my first shot at wiki participation, please edit/reply to [WWW]http://www.tallent.us if I'm breaking any social norms or posting in the wrong place.) Comments should not be viewed as "second-class" or even "special" objects at the specification level. The difference between (a) followup post from the same publisher, (b) a reply from another publisher, and (c) a common reader with a comment should be identical in form (save any "relationship" descriptor) since they are only distinguised by (a) who wrote them and (b) whether they own/use their own publication mechanism.

[RichardTallent, RefactorOk] (A point that may need to be moved elsewhere.) Why should "content" items and "related" ones even be separate classes? A better approach would be to consider "related" items simply as other "content" items and implement a content attribute that describes the relationship (e.g., 'related="cites"', '<related type="cites" mood="agree" strength="-5" />', or whatever). This also allows "related" and "content" items to otherwise share a common specificaton (media type, language, etc.), easing implementation. Such an attribute would also make clear that the other attributes of the entry (authorship, license, etc.) do not apply to the related item.

[RichardTallent, RefactorOk] This also solves a problem with content items: by default, they are interpreted as having the same license, author, etc., but this may be incorrect. Consider, for example, if I make an entry commenting on a work of art published as a JPEG: I want the work in question to be plainly visible as part of my entry in whatever software is used, not hidden under some "related items" link, so I make it a "content" item, but now it is mistakenly attributed to me in authorship and license, which may not be the case. A "related" attribute for such a content item allows it to become part of the entry while explicitly refuting the applicability of other entry metadata, and also allowing software to use this as part of its decision about whether or not to download the content.

Interesting. If Related were to be implemented with [WWW]XLink, there is a "show" function that gives the option to "embed" the linked content. For an Entry this could be interpreted as in Richard's use case.

[AdamRice] Any consideration to using an HTML-style <link> tag for this? The vocabulary for attribute values might need to be redefined a little (eg, add things like rel="parent"), but it seems to accomplish the same goals with less overhead.


Comments, Threads, and Dialogs have been historically constrained by 2D display (with experiments in 3D). Here since we're talking about the WellFormedEntry, we're in effect separating the data model from the client software that would display these relations. This is important because given a general network of relations between Entries, a lot of innovation will be needed in displays. See [WWW]Ideagraph - the aim is to use a comprehensive relationship model together with a 2D graph for working with this kind of thing. Also there's some good SVG visualization somewhere around David Jane's [WWW]Blogmatrix


It's important to note that container and parent->children relationships are easy if the entries are all in the same software system, but as soon as entries are decentralized it becomes much more difficult to maintain that model. child->parent is always easy. But the relationship isn't limited to parent-child (tree) - a post might represent the join of two separate threads.

Please expand on this. Given a handshake between two entries, much like Trackback, a two-way link model can be maintained.

Cases where that fails include:

Putting this in the frame of the WellFormedEntry, the entry won't accept and make available a reciprocal link. (Since we're talking about ideal Entries and the relations between them, ignore the case of can't accept.) One approach is to do nothing; that's the entry's perogative. Another approach is to use an annotation server, which would probably take the form of a minor feature of a general search engine. "Show me the entries that cite this entry."

How do you handshake between email posts?

If email posts are to be "entries" then they will have permalinks. With permalinks and client support for metadata, email posts can handshake.

[ChristianCrumlish] Is there room somewhere for the concept of "votelinks" - that is, the ability to link to a resource and signify a positive or negative (or neutral) value judgement in so doing?


[JeremyGray] I'm moving the text below onto this page because with Comment being an entry and TrackBack due to follow shortly, the text I posted elsewhere has become more relevant here than where it was.

[JeremyGray] With the page getting so long, I hope this doesn't get missed: To expand on IsaCommentAnEntry as some others have eluded to: Do trackbacks and comments not solely differ on where they are initially published? With that in mind, do we not have the following concepts:

Viewed this way, we're not really increasing complexity by opening things up to threading. Instead, we are recognizing the innate (threading) patterns which already exist and ensuring that they are addressed consistently and generically. A possible concrete result: a unified syntax and API for original entries, trackbacks, AND comments.


Related with XLink

Implement Related with an [WWW]XLink or with a subset of Xlink
Pro

Con

[SeanPalmer RefactorOk] If you're going to copy some XLink attributes, check out the [WWW]HLink specification. There's some W3C TAG dispute about it, too.

For quick reference an [WWW]XLink looks something like this:
XLink


CategoryArchitecture, CategoryModel