Refactoring in progress
Please take new discussion, and summaries from here, to Related
Proposal
Implement Related as
-
relationTitle
-
relationRole
-
relationLocator
-
relationAuthor
relationTitle, relationRole, and relationLocator as defined in the XLink or HLink specs.
relationAuthor defined the same as echo:author
Pro
-
Simple
-
Reuse parts of XLink spec
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:
-
Entry to Entry - to represent citations among entries
-
Entry to Containers - to represent objects that hold multiple entries - the base class for weblog, archive, syndication feed, thread, ...
-
Entry to Alternative - pointing to another log feed with an alternative view of the same information (such as with/without comments, a translated version, ...)
-
Entry to Other - pointing to any other URI, especially web pages.
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?
-
"unspecified" - any relation between the entry and another resource
-
"peer" ?
-
"parent" ?
-
"child" ?
-
"containedIn"
-
Yes : 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
content-by-reference discussion: ContentDiscussion, EntryContentDiscussion
"a complete list of outgoing links would make for a great (not-)Echo extension module..." diveintomark
TimBray 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 Echo and semantic blogging.
Early Discussion
Related supersedes and includes
-
CommentExtension: the number, location, and content for responses (comments, TrackBack, PingBack, etc. -- all of which might also be represented as entries).
-
ThreadingExtension: indicate what a WellFormedEntry (original entry or comment) is in response to. (See ThreadsML.)
-
RelatedExtension: indicates resources that the WellFormedEntry is related to
-
DialogMappingExtension: indicate if a followup or citation is an idea, a question, or an argument (pro or con).
-
The RSS link element
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
-
Entry A is cited by this (entry C ). Referring to a remote entry while located at my own log. Compare to
-
This (entry B ) is cited by a new entry (entry C) - Posting a comment.
(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 ThreadsML QuickTopic - some apposite notes can be found at 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)
-
The scope of Echo 1 isn't necessarily limited to current practice.
-
Specification of the form of an Entry can't resolve those issues. Related is a simple link data structure, which allows simple relations, rich relations and, yes, boundless complexity. Resolving those issues is up to application designers. Related just gives them a standard hook to work with.
[RichardTallent, RefactorOk] (This is my first shot at wiki participation, please edit/reply to 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.
-
[KenMacLeod, RefactorOk] I believe many people see comments, trackbacks, entries, etc. all as "first class" objects. Some (a lot?) think that an "Entry" model applies to all of them. This module, Related, tends to support that, by allowing each first-class thing to be related to any other thing. "Content" is the body of one entry; Related connects or organizes entries together.
[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.
-
[KenMacLeod, RefactorOk] This concept is less developed, where third party content is contained or inlined within the body of an entry. In some cases, it is can be made clear through using (X)HTML as the body content of the entry, and then using (X)HTML links and references to the other work. But it's not as well suited when the content might be the third-party content but the entry is due to the person who selected the content.
Interesting. If Related were to be implemented with 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 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 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:
-
the parent entry's systems can't or isn't configured to maintain child references.
-
static, archived, or historical resources.
-
the parent systems owner chooses only to reference certain children.
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?
-
This is like some features of DialogMappingExtension, which is included in Related. The key is to provide a simple Relation format that includes a specific Type. Then your application could define the Types eg {plus, minus, neutral}.
[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:
-
An original entry, unrelated to any previous entry, published by its author wherever the author publishes their original content
-
A trackback, related to any type of entry (original, trackback, or comment), published by its author wherever the author publishes their original content
-
A comment, related to any type of entry (original, trackback, or comment), published by the author of the entry being commented on, often because the person writing the comment does not have the facilities to generate a trackback
-
[AdamRice, RefactorOk] Am I reading this right? the entry-author is given as the comment-author?
-
[JeremyGray RefactorOk] If a Comment Isa Entry, which seems to be the consensus, then yes.
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.
-
[AdamRice RefactorOk] If you want to go really crazy, you could make comments into trackbacks from the same site.
-
[JeremyGray] Yes, and that's just a slightly different way of phrasing it. I would go even further and suggest that its not about making comments into trackbacks from the same site (as the entry on which they comment, though from a different author)... I would suggest that they already are.
Once you break down that barrier you can expose the whole landscape as being composed of entries and nothing but entries, where some entries are related to others and where entries can be hosted at an infinity of locations, not just at the entry author's normal hosting location, and that many of the terms we use now like comment, trackback, etc. are just colloquialisms we have invented for common permutations.
For example, a trackback is an entry, related to another, which is hosted at the author's usual publishing location. A comment, on the other hand, is an entry, related to another, which is hosted not at the author's usual publishing location but instead at the location hosting the entry to which the comment is related.
Seen in this light it is not hard to imagine the blogosphere as capable of being significantly more distributed than it is today, perhaps even to the point there an individual blog itself can be redefined as no longer a specific site assembled by a specific person to host specific posts but rather as (in most cases) a web-site-based aggregation of content which, through aggregation criteria, selects posts by a specific author. It would just so happen that in a good number of cases such aggregation/re-syndication sites would be created by the very author they (re)publish, allowing for that author's words to be initially hosted anywhere yet still end up integrated into a site which can present that author's voice in their own style, with their own layout, links, blogroll, etc.
Currently, a given blog hosts (at its top level, so that we can ignore comments for the moment) entries and trackbacks by that author, but with this extended thinking in mind there is nothing to stop it from also aggregating comments that author has made elsewhere, totally blurring the lines between trackback and comment to the point where the only difference is hosting location of the entry itself, noting that the entry's hosting location can easily be different from the location of its primary blog (that of its author).
Once that boundary has been broken, one can consider it alongside both individual (PC aggregation software) and large-scale (aggregation web sites) aggregation and re-syndication processes and see that hosting location could no longer matter, so long as a given entry can be attributed to the correct author, editable only by that author, and consistently located by other authors for the purposes of comments and trackbacks or whatever they might be called by the time the lines are that blurry.
Related with XLink
Implement Related with an XLink or with a subset of Xlink
Pro
-
Rich linking element will enable many applications
-
Alternatively, a subset of XLink can completely specify a rich link element for use by Echo
-
Reuse parts of XLink spec
Con
-
Full XLink element can't be completely specified for Echo, some parts don't apply
-
Requires xlink namespace
[SeanPalmer RefactorOk] If you're going to copy some XLink attributes, check out the HLink specification. There's some W3C TAG dispute about it, too.
For quick reference an XLink looks something like this:
XLink
-
title
role
resourceLocatorA
-
title
role
href
labelA
-
...
-
...
-
title
arcrole
from: labelA
to: labelB
-
...