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.)
- 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.
- 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.
maybe best done via WikiProxy?
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.