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

[Rufus Pollock]

Prodromos Tsiavos wrote:
> I think that Rufus's essay is particularly important for informing the 
> way in which we design solutions to support OK artefacts. All I would 
> like to add is that we may want to think of adding a fifth principle (or 
> make a variation of the incremental principle) so that we focus more on 
> the properties an OK artefact itself should concentrate:
> 
> For instance, I would add that the Open Knowledge artefact should always 
> be potentially unfinished or open.

Interesting. This seems to be a distinct but related meaning to open 
meaning 'open to alteration' (this would relate to the way in which some 
people tend to put out finished pieces of work under a no-derivatives 
license).

> In the first version of the essay it is not clear to me, whether Rufus 
> refers to 'open' under incremental in terms of open participation or 
> 'open' in terms of an artefact that is susceptible to continuous 
> improvements/ additions. I guess that the more 'completed' or 

Open here means open as in the open knowledge definition: 
http://okd.okfn.org/. I was suggesting that knowledge development 
generally would display these features but they are particularly 
relevant (and work best) in relation to open knowledge development. To 
take the code analogy: both open and closed source firms release 
packages but the system delivers best when you are dealing with F/OSS 
but you get the full advantages of decentralization and componentization 
(transaction costs are zero).

> 'self-standing' an artefact is, the less it is possible to be an OK 
> artefact. I would even go to the extent of arguing that the way the

I'm not sure I entirely understand you here. I think any piece of 
knowledge (artefact/resource that is nonrival) can be open but you might 
say that the less reusable the resource is the less it matters whether 
it is open.

> artefact is structured frames subsequent OK development interactions: 
> for instance the way in which the artefact is atomized (it is not all 
> artefacts that are atomized in the same way or even are susceptible to 
> atomization) to a great extent influences the development routines.

Absolutely that is something I wanted to go into greater detail about. I 
see a definite spectrum with some areas of knowledge much more amenable 
to this componentization compared to others. The classic examples where 
it is hard to componentize is narrative prose. It is generally not 
possible to take the start of one novel, the middle of another and the 
end of the third, stick them together and get anything resembling a 
decent new novel. In essence the problem is that narrative prose is 
highly coupled (to use a bit of terminology from software architecture): 
when you change one thing it generally has large knock-on effects 
elsewhere (anyone who has tried to tweak and old essay for republication 
elsewhere will know this all too well).

Something similar is true about music to a lesser extent though of 
course music can be incorporated into other types of works (such as 
films) and we do have whole genres based on sampling -- though the 
gluing effort even there is very substantial (perhaps this may be 
changing see the example given in [1][]).

Film provides an interesting example because here, though the finished 
product may be highly coupled, there is significant scope for 
componentization and atomization earlier on the production process. I 
remember Adnan talking about the process being developed at deptford.tv 
where one group of people would shoot footage, others would divide it up 
into 10-30s segments which they would tag and annotate with metadata and 
then others would come along and combine the segements into documentary 
films.

[1]: http://blog.okfn.org/2006/05/22/knowledge-packaging-for-content/

Overall I guess I current see a spectrum that looks like:

    Suitability for Applying the 4 principles (esp. componentization)

  Low       Narrative Text (Novels, Essays etc)

   |        Music
   |
   |        Film
   |
   V        Databases

High       Code


> To state it differently, is it enough to focus on the development 
> process as if all artefacts are capable of being subjected to OK 
> principles? Is the development process going to 'contaminate' the 
> artefact and make it open or are there properties in an artefact that 
> make it a bad candidate for OK development? and if there are such 
> properties, are they essential or accidental?

I think the question of the development process and whether the artefact 
is open are to a large extent orthogonal -- though as I said above I 
think this development process works best when the artefact is open. So 
I think you can apply this process to artefacts that are not open 
without 'contamination' though just as we are seeing growing tendencies 
towards F/OSS I believe we will see a growing tendencies towards open 
knowledge.[2]

[2]: http://blog.okfn.org/2006/11/06/open-knowledge-drives-out-closed/

> In overall, I would be very interested if someone disagrees or has a 
> different take on the whole issue or even thinks that the point is so 
> obvious that there is no need to discuss it at all.

Absolutely, and thanks for writing such a detailed reply.

~rufus

PS: I will be away and out of email contact for around the next 10 days ...