[okfn-discuss] What Do We Mean by Componentization (for Knowledge)?
Rufus Pollock
rufus.pollock at okfn.org
Thu May 3 09:15:38 UTC 2007
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 ...
More information about the okfn-discuss
mailing list