Wiki can be Wiki with more than Pages ThinkingOutLoud DonaldNoyes.20080307_20121204_20130528
This is a Wiki type which is composed of more than the pages which stand as its base.
(The following ThinkingOutLoud is being revised as several PersonalInformationCollections? via several processes (NysLte, NysArtifacts? and a revised NysWikiServer?) which are presently (2013-2014) being developed, compiled, presented, celebrated, and reposited at a web site (http://sunflowersynergies.org/default.htm). Containing some or all of the following:
The part above this line will be changed periodically by DonaldNoyes to represent his ThinkingOutLoud on this subject.
Comments
This sounds somewhat similar to an idea I'm playing with in my head which I'm tentatively calling 'Dataspace' (for want of a better name) at my journal at natecull.livejournal.com. The idea is basically an executable Semantic Web, used as a single replacement for a publishing system and desktop: instead of dividing data into filesystems and process trees, everything becomes a single 'executable memory space' of live data cells: something like a World Wide Spreadsheet (but a bit more general than any existing spreadsheet, SQL database, or RDF implementation). It is a concept that seems like it ought to be incredibly simple, but I'm struggling to try to map it onto existing languages or programming paradigms. Of all the stuff I've read so far, Ted Nelson's 'Xanadu' vision resonates the most (particularly his ideas about applications becoming personal hyperlinked information spaces called 'applitudes'), but I can't follow him entirely. Wiki also approaches the idea pretty closely, but it needs to become editable at a far smaller granularity than the 'page' - something like a global space of interlinked personal node-based wikis, where each node can have and be metadata for other nodes, and be seamlessly updateable in realtime as data sources change, is closer to my vision. This ideally would scale both up and down from a Semantic Web type global structure to a fast, lightweight machine-level parallel-programming framework.
My main motivation for exploring massive data-parallelism is not raw speed but a sense that a) data representation is just naturally parallel and we should not introduce artificial sequentialism or it will break the simplicity, b) most things we're trying to do in programming are just not that hard and life really should be a lot more pleasant than it seems it actually is right now. GUI programming in particular seems like it hurts far, far more than the simplicity of the underlying ideas needs to, and c) what we want in an age of the Web is massive democratization and massive data remix across multiple data sources and services; that means eliminating the difference between 'personal data storage' and 'personal applications/desktops', eliminating the difference between 'writing a program' and 'installing a program', and building something more like 'personal data dashboards' that receive, mix, blend and apply data and functions drawn equally from all over a globally distributed, locally cached utility Web, and that a reasonably interested 'user/programmer' could safely create without messing up the rest of the world, much like HTML enabled the creation of the first Web.
Of course, the hard part is trying to grasp the right abstractions for the first building blocks, and that's where I'm unstuck at the moment. I know I need some concept of a 'hierarchical namespace' (or dictionary) and a fairly simple 'publish, subscribe, compute' framework and a basic language/syntax, and it should be rather counterintuitively both *hardcore* pure-functional and *not* strictly typed at all (which rules out Haskell), but getting all the bits together to make the simplest possible working model still eludes me.
(It seems like RDF *ought* to be able to do this, but RDF has a lot of MissingFundamentalPieces? - primarily an actual programming *language* with DataParallelSemantics? that can itself be expressed in RDF.)
If anyone else has any idea of just what this paradigm is, because there must surely be a name for it, I'd love to know - it would save me a lot of effort if someone else has already built it.
-- Nate Cull
Related
You're all, without knowing it, groping towards the ideal of the GlassBeadGame