Transclusion is the mechanism of building content by including other content, possibly building an entire work by just including on little piece of content after another. So you start with little pieces of text A, B, and C that you combine into bigger pieces of texts such as D. D has no (original) content of its own. It just says “include A, include B, include C”.
Generally speaking, normal web pages feature transclusion of images, scripts, etc. You can link images A, B, and C into your web page D.
BtTempleton says that in the Xanadu Model, every fragment of text has its own identity. My “hello world” and your “hello world” are not the same object; in Lisp terms, they are not EQ. But if I edit version 1, “hello world”, to create version 2, “hello rabbit”, the span containing the first 5 characters of v1 and the span containing the first 5 characters of v2 are EQ. Transclusion is the only way to build documents; every document is just a series of “pointers” to the pool of available content. New versions of documents simply change some of the references to the “content pool”, so version compare is fast and accurate.
In a wiki context, all implementations implement only a very limited form of a special case of transclusion: TransQuotation?. It’s still a XanaLogical? idea, but it retains the “traditional” text model, without any of the power (or complexity!) of the Xanadu model. Whether the Xanadu model would work well in practice--or indeed, is even desirable in theory--is debatable, but since TransClusion is one of Xanadu’s key innovations, it’s good to keep in mind that wiki-transclusion does not approach the full generality of the Xanadu text model.
See also MeatBall:TransClusion.
Some issues that might arise in this context:
For more about the technical aspects of wikis and transclusion, see WikiTransClusion.
Oddmuse:Transclusion works on this wiki, too. On a line of its own, write:
This will transclude the page FooBar at this very location.
Furthermore, Oddmuse support transclusion from other Oddmuse (and compatible) sites by simply incorporating the source site’s URL.
I am supportive of some type of assistance for writing long pages based on technical tools, since I too am struggling with the issues of “What is a page anyway”, and am currently trying to define a set of personal page styles. What I have found so far…
Notice how the Oddmuse implementation of the calendar allows you to do that – you can click on the month and it collects the appropriate pages. Notice also how the Blog page uses a tag to collect the latest DatePages. And yet we don’t really use organization by time. Why? Because we like to think that our contributions will remain behind as artefacts of our discussion – for future readers – who care very little about the temporal context but who care a lot about the linking context. And the link context is very easy to establish on wikis by writing the names of pages. Clearly, the name has to relate to the topic of the page. If the name of the page is a date, then the value of the system decreases…
Alex: Thanks for re-locating the text.
Obviously, I’m still struggling with when to follow the Wiki:WriteWhereTheyRead principle (especially when keeping text in-line, even when it’s a tangential comment), as opposed to refactoring the page.
Perhaps the ideal action would have been to make replace the text where I first had it with a link to the TransClusion page (as you did), together with a named anchor. That would have preserved the original contextual information (not that its important, in this case) at the same time as the block of text itself is then positioned in a more appropriate context.
This is of course, exactly what I use TransClusion for in my personal wiki. There, I create a miniPage that is the block of text in question, and then I simply Include it in both places. Obviously, this is not a panacea, since it certainly does not resolve the fundamental problem of when text should appear in-line, as opposed to simply being a link. However, in my experience, this decision is driven by the Author’s level of mastery of the “Know your Audience” precept. As such, it seems to become a matter of judgment in each particular instance. This is why I appreciate tools that allow me to have the choice.
With respect to my example based on Dates, I used it purely as a convenience to illustrate the evident levels of inclusion. I probably should have taken the time to use a hierarchy other than the time domain, since I did not mean to raise the issues related to WikiNow.
What the Xanadu Model makes me want to do, is a TransClusion of sections only from a document. I’m currently using Mediawiki for a personal use (one user), as I am auditing an organization. So I collect information, that I try to sort out into pages, that are classified into categories : “Applications”, “People”, etc.
In this context, when several people talk to me about, say, “Application X”, and then explain to me what difficulties they are faced to when they use this application, I try to structure their respective pages (or restructure them a posteriori) with an identical hierarchy of titles/sections:
John Dew :“Application X” (Level 1) :“Difficulties” (Level 2) :“Benefits” (Level 2)
It would be very useful then, if I had the possibility to “transclude” into a page named, say, “The Application X”, within a section “Difficulties”, all of the sections “Difficulties” from each people’s individual page, in order to synthesize this information.
The need comes when “Application X” is mentioned by a sufficient number of users. It becomes relevant then to consider this application as a sort of a “node”, where to think about this specific application and its problematic. To say it another way, i want to build a new Pointofview around this application. So I want to work directly inside this new page, considering that the opinions of all users regarding this application are resources that feed this Pointofview (a different perspective would be if an application is related to only a small group of persons, in which case the information about this application would feed a Pointofview centred around this group of users)
So I’m going to publish information directly into page “Application X”, because it’s the place “i’m sitting in” when I need to think about this application.. But I need that the modifications made at this page level (for example when i update one user’s “difficulties” - the way to do it being to look/modify other users information at the same time, side by side), to be propagated into the original individual pages: - for data consistency, - to be able to build different Pointsofview, later.
Ideally, thinking about the GUI, it would be great to have a dynamic page option, that would make it possible to “fold” and “unfold” this compilation of users “Difficulties” within this section “Difficulties” (that synthesises them inside the page “Application X”) : so it becomes easier to build a summary within this Page/Pointofview (a summary that will remain “located” at this page level)
Well, that’s just a description of one need i have when i think about Transclusion. I hope i expressed it clearly – SébastienSauteur
I think your problem is a result of the emphasis placed on the page as a work unit. This is probably because of the user interface. Your users edit pages. You edit pages. Pages have sections. Pages are text. They are saved in tables or files.
The correct approach would be different, hower: Write something about application X here, something about problems with application X there, something about the benefits elsewhere. Then you have the kind of text modules that you can assemble into pages about application X, benefits of all applications, difficulties with all applications, etc.
One way to solve this problem using software would be to automatically split pages you write into named sections according to headings, and allow you to include them elsewhere. If you could then not only tag pages, but individual sections, too, then you’re deliberately blurring the difference between page and section. Both have a name, both can be linked to, both have tags or categories, and both can be reassembled into new pages.
Well, i guess using the term “page”, i meant a way to organize information at one given time, to reflect one point of view, in one decided structured manner, so that you can print it out (real page), or show it to someone on screen. May be i should have used the term “document” instead, a document based on bricks of information.
In my example, when i meet people first, i write down the interview onto a real paper page, and i come up with notes. I’m actually working on a subject that i’ve never heard about before. So, even if i don’t really know where i’m going, i prefer to have this information filled into an almost monolitic “page”, rather than kept on paper. I bet on the wiki But you pointed at it : i need to split that first big “page” into sections, so that i can reassemble them afterwards, in other documents. And so i need to have tags - or similar- to tell what the section is about.
Further on : could it be useful to have a first automatic section-tagging process, based on headers : in the example above, the section “difficulties” under ‘application x”, under “John dew”, would be tagged 3 times : “john dew”, “application x” and “difficulties”. I could then manually add another tag, for example “july”. Then in a new document, i could tell a script to transclude all the sections that are tagged “application x” AND “difficulties” - may be could i have some qualified (?) tags, like “user:john dew” instead of “john dew”, and “date:july”, so that i could sort the list of transclusions by names or date ? And then in the final document, made out from those reassembled sections, i would only edit original information. But does any wiki-software allow me to do that, at this time ?
I like the emphasis Alex places on Page and Section enough that I’m going to try to develop a set of characteristics for each. In doing so, I think the concept of a Block (a component of a section?) may also be worth considering. It may also be worth looking at the other Objects that usually appear within a page, such as images, or charts, Ideally, it may even be possible to incorporate some of the aspects of various MicroContent discussions and perhaps even the concepts of related to the dynamic “sliders” TiddlyWiki has introduced.