AppWiki

AppLog defines a background idea of providing WebLog-like views (native and via RSS) of any WebApp (or other app?) where chronology has any relevance. AppWiki's a slightly weirder idea, going further into Application Integration.

(Kinda like a ReST/Web Services approach to loose user-focused integration - only not for automated transactions requiring perfect mapping aka Semantic Web, but for local links for humans jumping from app to app (where some failure is acceptable).)

(Should this be called Semantic Wiki? Probably not.)

Each app tends to have key objects/entities that a user would like to refer to. Use a Smashed Together Words model to define a Canonical URL for that object within that application

• actually, that doesn't need to be the canonical URL, it just needs to be a working URL
  • you may automatically generate WikiNames for objects (firstname + lastname, etc.). Then assume there may be occasional failures of uniqueness, so treat it as a search which may return more than 1 record.
• this has value even within a single application for increasing Intertwingularity. I've made such recommendations for OSAF/Chandler.

Use an InterWikiMap model to define a distinct NameSpace for each of those apps. (Maybe that makes it InterApp Wiki.)

• Then, within any text field in an app, one could refer to an object in another app via its InterWikiMap-like name. And that server app would auto-generate an HREF to a view of that object.
• And/or you could define those apps as Sister Sites, which would allow a given object to be described in multiple places, with easy linking across them.
• hmm, I wonder whether the InterWikiMap NameSpace directory will just end up recapitulating the DNS NameSpace problem?

As a baby-step, there is some benefit to at least supporting a RemoteWikiURL model for linking to a recordId in a remote app.

see also Object Browser, Universal Inbox

maybe best done via WikiProxy?

As this increases the perceived integration of multiple WebApp-s, it may raise the importance of converging toward a SmartAscii standard...

Me too, I am a fan of the simplicity of the Wiki NameSpace. But I guess the only reason it is needed is because we are still dealing with the row/column model of PlainText. And this will not lead us anywhere Really Useful.