''Beauty is in the eye of the beholder''. By the same token, ''knowledge is perceived by an individual'' - it depends on personal experience, background, culture, memory, remembrance...independant of accompanying and descriptive information.

I believe that there is a fundamental representation of knowledge resulting from the decomposition of features from data in all its varieties and that fundamental representation is a multi-dimensional pattern. The biological analog of that pattern is a brain. A brain grows to envelop newly perceived features in data received through not only the senses, but also the interrelationships within the data itself. I think of the brain like the roots of a tree that receive "nutrition" from data. New tendrils grow as new features are discovered within the data and the complexity of the data stimulates the growth. The system is self-organizing and can create implicit relationships in the absence of explicit relationships. I imagine bits of unrelated data "dangling" on the ends waiting for their contextual connections. My goal is to model this process in software.

Janie: ''Beauty is in the eye of the beholder'' - when he looks at something; or has had a look at something, gained the beauty of it and established a sort of imagination of beauty. Never having had a look at something makes it difficult to develop an imagination or concept of beauty. So there is a need for an object here. Similarly, knowledge isn't independent of something outside the individual, and that - decomposed into features, as Scott is suggesting - must be internalized: through sensual perception, if it's material; or mental reflection, if it's conceptual; or mental affection, if it's emotive. In any case, some sort of information needs being internalized to get knowledge. One of the basic questions therefore is if and how that information which is needed to get to know something can be represented formally.

Further, if we take human made artifacts into view: these typically bear some purpose or function, which stems from knowledge the maker puts into the artifact. So he externalizes his knowledge - not necessarily explicitly, but eventually also implicitly. If we now extend our look at the making of an artifact by a number of individuals in collaboration, another question arises: if and how not only the explicit, but also the implicit knowledge can be shared by utilization of means of formal representation of information involved.

Scott: " ... features in data received through not only the senses, but also the interrelationships within the data". That's the point, these interrelationships within the data. If they cannot be decomposed - if they can, it's becoming data again -, can they be represented formally, and how? I think this is a basic issue with your trying to model the process of the creation of interrelationships, if the latter is not just a fuzzy, but intentional process.

I think the interrelationships are discovered and are themselves patterns of context that join content. The "dangling" entities become joined contextually. Without context they are useless. I don't believe there's a differentiation in the mechanisms that decompose content versus context.

I'm thinking about this in a purely mechanistic way though. Describing puzzle pieces and the process of assembling them opposed to/with the purpose of completing the picture.

Regarding the approach of formalizing knowledge is based on types of knowledge - tacit or explicit. There should be different mechanisms of formalizing these knowledge. For example, explicit might be easier to represent in the form of report, document, database. etc. Tacit is handling directly from individual to individual or organization to individual, and even vice versa. Social interaction plays important role as mechanism for tacit knowledge sharing. It's complicated to formalize the tacit due to the nature of knowledge. I hope i can touch some parts of the question.

Frank: You are right, the interesting thing is the transformation process. It works on, be it a data file, a functional description, an equation, a textbook, a scientific theory, even a material object like a machine or device or tool, and whatever else you can think of bearing some knowledge which shall be made use of. In an earlier paper we suggested the term 'knowledge object' as an abstraction, indeed. And investigating ways of sharing the knowledge inherent to such an object means to understand what you call the transformation process, which in our understanding is mediated by interfaces. These interfaces must relate to the knowledge object in an appropriate and useful way. That's why we are asking what these interfaces shall include, and how that can be represented best.

The data representation is task-oriented. If it is suitable to use contextual information in any form (like, ontology or plain text) - so be it. If it is useful to present audio and video, or 3D-range sensor data or IR-picture - so be it. If it is useful to present reports or charts - so be it. The question is - what is required by the task

Frank: Take software engineering as an example. Software engineering models are the abstraction of the development process, specifying what the process involves in terms of development stages and artifacts. So you have workflows (or processes) here, operating on artifacts (or knowledge objects). One of the issues with artifacts (also including interfaces, of course) is that they are (need to be?) static at the time they are introduced in a workflow. When the use/application environment changes, this static nature may become a shortfall, as you say. Dynamism (ar adaptivity) gets interesting therefore.

Abstract objects, however, must be related to instantiations of artifacts as soon as a function is applied - for standardization purposes, but also for risk mitigation and management purposes, and others. This becomes an obstacle to total abstraction. Hence the need for balancing abstraction and instantiation.

Nevertheless, I agree it does make sense to try and extend process models towards abstraction. In the case of for example complex systems development, any developoment process model becomes complicated, as to the workflows as well as the objects involved. The balancing need then calls for a multi-dimensional approach. We are trying to address this in our explorative work on a multidimensional unified process model.