together different files. Similarly when creating a dataset in a database we divide things into columns, tables, and groups of inter-related tables.
But such divisions are only visible to the members of that specific project. Anyone else has to get the entire application or entire database to use one particular part of it. Furthermore, anyone working on any given part of an application or database needs to be aware of, and interact with, anyone else working on it—decentralization is impossible or extremely limited. Therefore, atomization at such a low level is not what we are really concerned with; instead it is with atomization into packages.
- 7. 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” purpose comes into play—without it there is still tight coupling between different parts of a resource.
Developing packages is a non-trivial exercise precisely because developing good stable interfaces (usually in the form of a code or knowledge API) is difficult. One way to provide stability but also to 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 stay using 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 open knowledge.
- 8. Componentization for knowledge
At present, knowledge development displays very little componentization but, as the underlying pool of raw, “unpackaged” information continues to increase, there will be increasing emphasis on componentization and the reuse it supports. One can conceptualize this as a question of interface versus content. Currently 90% of effort goes into the content and 10% goes into the interface. With components this will change to 90% on the interface 10% on the content. The change to a componentized architecture
