![[Home]](/static/logo.png){kind=logo}
Mobile Content is content that is easy to move from wiki to wiki.
Right now, moving pages from wiki to wiki is an involved process.
Hm. Looks pretty involved.
Mobile Content automates the process of moving content from one wiki to another wiki, in a safe, complete, and easy way.
Furthermore, there is room for error. In a future of WikiFutures:RegularlyDividingWiki (WikiFutures:IdeasToPlace #59), there will be a lot of transfer of content, and people will likely forget about which wiki has which license.
In a future of WikiFutures:RegularlyDividingWiki, when a wiki divides, we’ll want to send many pages to many wiki.
Because pages are inter-linked, it makes sense that we frequently want to move entire collections of pages at once, rather than just one here, just one there.
It would be nice to have a page for performing a batch page transfer.
The batch transfer page would have two columns. On the left, you list the pages that you are exporting. On the right, you list their corresponding names on the new page, defaulting to the same name as on the left. Somewhere on the page, you name the target wiki.
When you press the “send” button, all pages in the group are delivered.
Yes, there are good reasons why many of us do not like CommunityWiki:DigitalRightsManagement.
However, there are reasons to like it in our wiki. The WikiLegal:CopyleftInteroperabilityProblem is real. We’d like our copyrights to mean something.
If you transfer a page from a wiki with the WikiLegal:FreeDocumentationLicense to a wiki with the WikiLegal:CreativeCommonsShareAlikeLicense by accident, that can be very bad.
Since WikiFutures:RegularlyDividingWiki (WikiFutures:IdeasToPlace #59) is likely to be spurred by the WikiFutures:MassUseOfWiki, it makes sense that there will be a lot of wiki, and that it will be very easy for people to get licenses confused between wiki.
When wiki transfer MobileContent between themselves, it makes sense for them to compare licenses with one another. Each wiki would have a code, specifying it’s license, and a protocol for negotiating what the wiki will accept automatically or not.
Now, suppose that a person was the original author of an entire page, and they want to transfer it from a wiki with the GFDL, to one with the CCSA. There are two ways of dealing with it. One, the wiki could note that the person who is transfering the page is the sole author of the page. Or two, the author could manually transfer the page over, the old fashioned way.
(Note, in the case of a page that has had many contributors, it is conceivable that the wiki could keep track of every person who has ever edited a page, and consult them on permission to transfer. See BundledPages, IdeasToPlace #93, for notes on the idea.)
A target wiki may not want to accept the changes, right away, without some deliberation.
Or, a page may be sent which has the same name as an existing page.
In anticipation of these situations, the target wiki may want to have a “receiving area” for pages. The pages come into the receiving area, and are accepted (and perhaps renamed) as part of some sort of trusted process, or by consent of some sort of authority.
Different WikiEngines have different WikiSyntax. For example, on MoinMoin, you use // to make something italic, on another wiki, you may use _ or / to make something italic.
When you transfer pages, you generally have to go through the page, and change every form to some other form.
You also have to fix links. You have InterLinks, and you have LocalLinks. If a link is local, and not part of the same batch transfer, then you need to attach an InterWiki link back to the source wiki.
If an InterLink points to a wiki that the target wiki doesn’t have on it’s InterLink map, then you have to make it point with a full URL.
(Or, alternatively, wiki could extend their InterLink map.)
When you manually move a page over, you can’t transfer the Page History as well. That means you lose quite a bit of important information when you transfer a page.
If we have BundledPages (IdeasToPlace #93), this point is moot: Transfering a page transfers all of it’s associated meta-data as well.
But if you don’t have BundledPages, you may want some way to transfer (and translate!) the version history as well.
Possibilities include:
When you are about to ship a bunch of content, you could wait a period of time before actually performing the shipment. Both source and target wiki would receive notice that a shipment was planned, and an authority or trusted process could be used to cancel or accept immediately.
See also: DelayedCommits
Pages could be both moved (delete on source, add on target) or copied (just add on target).
Someone (who doesn’t know about wiki ?) once said:
I think NNTP – the protocol used by Usenet newsgroups – is the way to go for discussion groups or any type of shared (non-personal) “mailbox.” Collaborative filtering works well in this distributed system. – http://deflexion.com/archiveb/2003_11_01_.php#106968751254380891
NNTP uses “cancel” messages to get rid of unwanted Usenet posts.
Could/should something that looks like Wiki be built on top of NNTP ? Perhaps like this:
When all the Wiki-like software connects to a single NNTP server, it looks and acts exactly like any other wiki implementation.
Yes, this conversation does go on another page- but we don’t have to worry about that immediately. In general, I’d say: If you don’t know where something goes, put it in IdeasToPlace. But this is a long entry, so in that case, if you still don’t know where it goes, either make a new page for it, or, perhaps better, put it on your CommunityWiki:FrontLawn. (That is, the page called “DavidCary.”)
I think you could make something like Wiki on top of NNTP. But, I don’t think we should, because I don’t know what benefits it would bring, and NNTP wasn’t really made to support things like wiki.
It’s true that HTTP wasn’t made to support wiki either, but the concepts are closer between HTTP and wiki. HTTP is document based, NNTP (I believe) is message based.
I do think it’s valuable to be able to interact with a wiki in a threaded way though. I think you like NNTP because it’s easy to have a back and forth conversation on Use``Net- is that right? Wiki certainly has a lot of room for improvement in that area.
I think the best thing to do- as far as improving wiki threaded interaction- is better support for MailedUpdates, and then- not just MailedUpdates, but also the ability to hit the “reply” button, send a reply to the wiki, and have it automatically appended to the page. I believe that I wrote that idea up in MailedUpdates.
I suppose another nice thing that Use``Net has, that wiki doesn’t, is that you don’t have to “subscribe” and “unsubscribe”- everything is just there, nicely organized. I believe that auxiliary systems to wiki can be set up to support this notion. Hmm…
Any ideas?
None, yet!