Re: [ba-ohs-talk] Knoweldge Apps Foundry on SourceForge
+1 as Well. How Would one define a knowledge app? An interesting issue
regarding the formation of a foundry is the presence of multiple content
management (blogging) packages which are pretty related, but whose
inclusion might drown out the other knowledge app issues. (01)
Personally, I am most interested in applications which deal with *knowledge
classification*, specifically the placement of short blurbs of data into
some sort of structure. However, this type of definition does not clearly
include dialog mapping, which is more about knowledge representation. (02)
So... what's a good short definition of a knowledge app that would include
Wiki's + dialog mappers, but would exclude simple chronological blogs? (03)
--Alex (04)
At 11:30 PM 3/4/02 -0800, you wrote:
>+1
>
>Jack
>
>At 10:30 PM 3/4/2002 -0800, you wrote:
>>For sake of exposure, I strongly recommend that we approach sourceforge and
>>start a "knowledge applications" foundry. There are lots of other people out
>>there developing isolated pims, graphs and collaboration tools. We need to
>>get them together. I suggested this once a long time ago but received little
>>support. Perhaps this time the community is ready to give it a go. One of my
>>problems was that I couldn't well define "knowledge application". Maybe we
>>can use Douglas Engelbart's criteria for the OHS.
>>
>>(
>> knowledge apps foundry on sourceforge:
>> http://www.memes.net/index.php3?request=displaypage&NodeID=462
>> )
>>
>>...Steve Danic
>>www.memes.net
>>
>>
>> > The OHS consists of the universe of "knowledge
>> > applications" that implement a common feature set in an interoperable
>> > manner. Those features are well-documented in Doug's papers -- granular
>> > addressability, view control, backlinks, etc. This feature set is also
>> > usually what's emphasized when describing the OHS. I find this
>> > unfortunate, because what Doug emphasized in his papers is the really
>> > important stuff -- namely interoperability: (05)