[okfn-discuss] What Do We Mean by Componentization (for Knowledge)?

Wed May 2 19:30:54 BST 2007

hi Rufus,

Wow. That's a seriously thought provoking nodule of knowledge.

On Tue, May 01, 2007 at 12:53:33PM +0100, Rufus Pollock wrote:
>   1. Incremental
>   2. Decentralized
>   3. Collaborative
>   4. Componentized

You could argue - while explaining the others in super-short-summary
that the fourth element predicates the first three to a great degree.
That's why it's the 'most important' one - which otherwise sounds a bit
unwarranted.

> The power and significance of componentization really comes home to one 
> when using a package manager (e.g. apt-get for debian) on a modern 
> operating system. A request to install a single given package can result 
> in the automatic discovery and installation of all packages on which 
> that one depends. The result may be a list of tens -- or even hundreds 
> -- of packages in a graphic demonstration of the way in which computer 
> programs have been broken down into interdependent components.

An example of a knowledge-like package might be good here. The one I
usually use is 

apt-get install anarchism (try it!)

I thought this was a great example, until I actually read the anarchism
FAQ installed by the package at /usr/share/doc/anarchism. It starts
really well, a very clear, well presented historical and contemporary
account of the political and economic theories and examples of
anarchism. Then in /usr/share/doc/anarchism/html/secA3.html it begins to
repeat itself, contradict itself - and becomes almost unreadable in
parts.

Perhaps it's a poor choice of example, 'apt-get install oligarchy' might
be less of a mess. However, the point is that even with versioning,
wikis, packaging etc. 'Knowledge' 'data' and 'information' are
qualitatively distinct, and it would be good to address that thorny and
inevitably philosophical issue somewhere in this text or in a
discussion following it.

> Thus, atomization at such a low level is not what we are really 
> concerned with, instead it is with atomization into **Packages**:

Perhaps that's the nub of the issue - what is the lowest level we can
bring ourselves to agree to? Distinguishing between atomisation and
packaging is a neat way of skirting the long-standing phenomenological
issue about what knowledge *is* - a shortcut which I appreciate in the
interests of pragmatism. But maybe we can take a pragmatic punt at an
answer.

For me - this was one of the most interesting questions at OK 1.0 - and
An Mertens' intimate session on 'Atomic Literature' in the Map Room at
Limehouse was a really interesting response to the issue.

She drilled down from expansive questions knowledge is - to a more
specific question about what the specific infrastructures are that
support the creation, interpretation and preservation of that knowledge:
experience, mediated by language, notions of individuality and
associated traditions of authorship. She started telling us a story in
English, then switched to French, with a Flemish accent, then to Flemish
with a French accent, repeating the story - then to Franglais with some
Flemish words thrown in - repeating the story again for good measure.
It was an enjoyably disorientating performance.

As a Flemish language feminist sci-fi author, I imagine that An Mertens
often finds herself stuck between genres, languages, and accents. Her
reading/performance, accompanied by a dry slideshow of digital photos of
her flat, Brussels, the train station, the flat she was staying in near
Angel tube... it was a big mess of contexts, with her uses and
reflections of various languages and accents packaging and then
unpacking them for us.

The point is - there are as-close-as we can get to irreducible elements
in there. Wordnet is a good example, a growing number of semantically
coherent bibliographical systems enabling automated or augmented
cross-referencing systems across multi-lingual translations. This is not
to mention the many language resources, speech synthesis and recognition
systems that are being developed in the Free Software world (many for
niche languages that can't otherwise afford such an infrastructure.)

Basically - I'm saying let's not back down from taking Atomisation
seriously. An Merten's performance might have seemed like a Dadaist
experiment in literary performance, but I thought it was exemplary of
how a package might be almost incomprehensible, but how the component
parts might themselves be re-usable. Rather than 'divide and conquer',
her presentation was asking us to integrate a bunch of disparate
linguistic and graphical elements of Atomic Literature into a new
package of our own.

> ## Packaging
> 
> By packaging we mean the process by which a resource is made reusable by 
> the addition of an external interface. The package is therefore the 
> logical unit of distribution and reuse and it is only with packaging 
> that the full power of atomization's "divide and conquer" comes into 
> play -- without it there is still tight coupling between different parts 
> of a given set of resources.
> 
> Developing packages is a non-trivial exercise precisely because 
> developing good *stable* interfaces (usually in the form of a code or 
> knowledge API) is hard. One way to manage this need to provide stability 
> but still remain flexible in terms of future development is to employ 
> versioning. By versioning the package and providing 'releases' those who 
> reuse the packaged resource can use a specific (and stable) release 
> while development and changes are made in the 'trunk' and become 
> available in later releases. This practice of versioning and releasing 
> is already ubiquitous in software development -- so ubiquitous it is 
> practically taken for granted -- but is almost unknown in the area of 
> knowledge.

There are many equivalents - drafts and re-drafts and various academic
practices that could be examined for parity with versioning. McKenzie
Wark tried to write his last book with a kind of 'paragraph' packaging
level of statements with a versioning system (built on Wordpress!) and
himself as the BDFL making final edit decisions; an interesting attempt. 

> ## A Basic Example: A Photo Collection
> 1. Bundle all the photos together (zip/tgz) and post them for download. 
> 2. In addition tag or categorize the photos and make this database 
> 3. In addition suppose the photos fall into several well-defined and 
> 4. In addition to dividing them up allow different people to maintain 
> 5. Standardize the ids for each photo (if this hasn't been done already) 

I get it - but I think more complex / arguable examples might also be a
good illustration for such a bold claim.

> The change to a componentized architecture will be complex but, once
> achieved, will revolutionize the production and development of open
> knowledge.

Great conclusion - and I think you're right. Infrastructure first, then
practice will catch up. I guess that's why it took so long for Free
Software to emerge from first principles of timesharing and code sharing
on mainframes - it took from the 60's to the 90's for the knowledge
infrastructure to catch up with the needs of the operators and their
economies.

Cheers,

Saul.

-- 
The People Speak   | 17-25 Cremer St.  London E2 8HD | http://theps.net
studio +44 (0)20 71007915 | saul: +44 (0)7941 255210 | ms at theps.net