CONTACTS 
0201 - Armstrong Consulting
020101 - Mr. Eric Armstrong

SUBJECTS
Difficult KM Hard to Design, Not Understood
Core Capability KM Not Understood, Eric Armstrong
KM Not Understood Secret of SDS
XML OHS Design Ken Holeman New Contributor
Holeman, Ken, Meeting on Using XML for KM Design, Eric Submits Notes
OHS/DKR Meeting at Doug Engelbart's House with Ken Holman on XML
XML Not for Storage nor Knowledge Representation
XML Should Not Be Addressed at This Stage of OHS Development, Ken Hol
XML SGML Knowledge Representation Atomic Data Strucutres Strive to Pr

2511 -
2511 -    ..
2512 - Summary/Objective
2513 -
251301 - Follow up ref SDS 50 0000, ref SDS 49 0000.
251302 -
251303 - Received ref DRT 1 0001 from Ken Holman following up meetings reported
251304 - on 000113, ref SDS 50 5Y6G, and on 001114. ref SDS 51 5Y6G
251306 -  ..
251307 - Ken says in his letter today that XML is not a panacea and XML-related
251308 - recommendations have distinct roles and give us valuable tools for
251309 - certain things. ref DRT 1 IL7K
251311 -  ..
251312 - Ken clarifies understandings that the OHS/DKR team expects XML
251313 - technology can be a core "independent" storage mechanism in a
251314 - classical "hub and spoke" architecture where its use would be mandated
251315 - as the target transformation format for the importation of external
251316 - documents and internally synthesized information.  Somehow an OHS XML
251317 - vocabulary would be developed for the collection and maintenance of
251318 - information in the system. ref DRT 1 VO9M
251320 -  ..
251321 - I truly think this is an inappropriate application of the technology.
251322 - ref DRT 1 PS4K
251323 -
251324 -     On 000405 Paul Fernhout reported XML does not solve knowledge
251325 -     representation problem. ref SDS 14 0005
251326 -
251327 -       [On 010131 Cliff Joslyn recognized that PDF and wordprocessing
251328 -       are not effective for KM. ref SDS 52 LF7M
251330 -        ..
251331 -       [On 080104 Morris considers switching to Java for programming
251332 -       XML design for SDS Windows application. ref SDS 53 OM6Y
251333 -
251335 -  ..
251336 - XML Supports Interchanging Information
251337 -
251338 - Ken cites information from Nicolas Carroll submitted on 001124...
251339 -
251340 -         Was glad to hear that -- in his view
251341 -         XML is the glue, not the construct.
251343 -  ..
251344 - Ken comments...
251345 -
251346 -     Yes, ... XML is an excellent technology to apply to the problem of
251347 -     *interchanging* information between possibly (though not
251348 -     necessarily) disparate stand-alone systems, or even subsystems
251349 -     within a larger system.  The systems could be from different
251350 -     vendors, from different users, or even two systems used by a given
251351 -     user over a period of time such that the systems are incompatible
251352 -     (thus exploiting XML for archiving). ref DRT 1 0Y5L
251354 -      ..
251355 -     XML is a syntactic expression technology ... it isn't designed as
251356 -     an active storage technology, or an internal representation
251357 -     technology. ref DRT 1 4Z6O
251358 -
251359 -       [On 080104 Morris considers switching to Java for programming
251360 -       XML design for SDS Windows application. ref SDS 53 OM6Y
251362 -      ..
251363 -     XML can possibly be used in the interface between the Hyperscope
251364 -     and the back end, where this interface is over HTTP or a network
251365 -     of some kind ... but certainly not in some tight programming
251366 -     interface just to "say" it is implemented in XML. ref DRT 1 UQ4K
251367 -
251369 -      ..
251370 -     XML Should Not be Addressed at this Stage of OHS Development
251371 -
251372 -     While hard code is definitely required to reify the results of our
251373 -     labours, I am trying to convey the need for a definition of what
251374 -     needs to be done, not how it is accomplished.  I think thinking
251375 -     about XML syntax is *not* needed at this point and applying it
251376 -     will be a necessary process down the road to address certain
251377 -     requirements ... but not yet. ref DRT 1 XM4F
251379 -        ..
251380 -       [On 080104 Morris considers switching to Java for programming
251381 -       XML design for SDS Windows application. ref SDS 53 OM6Y
251383 -      ..
251384 -     So, since I wholeheartedly believe focusing on XML isn't
251385 -     appropriate at this stage of OHS development, I shared at Doug's
251386 -     two meetings what I think should be done. ref DRT 1 4N4L
251388 -      ..
251389 -     From what I understand of your requirements, however, I see no
251390 -     need to mandate* the use of XML syntax internally or to decide yet
251391 -     on any ind of finalized syntax. ref DRT 1 XO9J
251392 -
251393 -
251395 -  ..
251396 - Services Primary Initial Focus OHS Architecture
251397 -
251398 - Ken confirms Eric's notes for the meeting reported 001113 to focus on
251399 - OHS services. ref SDS 50 FV7I  Ken calls this "services definition".
251400 - ref DRT 1 PT5F and ref DRT 1 557K
251401 - ..
251402 - Ken, also, confirms Eric's notes for the meeting reported on
251403 - 001114 that Ken misunderstood that the Hyperscope was the "user agent"
251404 - of the system and the OHS was the services/repository "back end" of
251405 - the system. ref SDS 51 4FYW  Having since heard the DKR (Dynamic
251406 - Knowledge Repository?) acronym, Ken feels that could be the back end
251407 - and the OHS be the label of the entire system. ref DRT 1 HZ5N
251409 -  ..
251410 - I thought the user interacts with the OHS through the Hyperscope.  The
251411 - Hyperscope is the user agent that  marshals user requests and feedback
251412 - to and from the back end of the system.  All the requests and feedback
251413 - would be described as a well-defined set of services and responses:
251414 - the "services definition".  The communication methods between the
251415 - Hyperscope and the back end would depend on where and how the
251416 - particular implementation of the system was built.  A given Hyperscope
251417 - might interact with two different back ends, implemented in two
251418 - different ways, based on the connectivity provided the user in the
251419 - environment in which the user works. ref DRT 1 K46K
251421 -  ..
251422 - But I believe that abstractions are inherently scalable!  Start with
251423 - an abstraction of a very simple task, get an implementation reified,
251424 - deploy it, learn from it, build upon the abstraction with new
251425 - services.  If an implementation has to change to support the new
251426 - services, the abstraction itself hasn't been broken.  If by innovation
251427 - a particular implementation doesn't need to change, all the better for
251428 - that developer, but the system design hasn't imposed restrictions on
251429 - how a developer implements the abstraction.
251430 -
251432 -  ..
251433 - Ontology May be Another Name for Services
251434 -
251435 - Then came the meeting Tuesday where Jack and Howard attended.  I met
251436 - Jack first in June in Paris at a Topic Maps organizational meeting
251437 - (I'm trying to keep involved in that XML arena as well). ref DRT 1
251438 - 446H
251440 -  ..
251441 - I learned from Howard that an ontology is a description of the
251442 - processes of a system without including particular concrete examples
251443 - or implementations of the system (the running of a department store
251444 - vs. Macy's).  I heard Jack talk about the urgent need to first develop
251445 - the OHS ontology.  At one point Jack mentioned about the IDL of the
251446 - ontology. ref DRT 1 X46L
251448 -  ..
251449 - This was the "a-ha!" for me ... this was where I realized that what I
251450 - call a "services definition" is what Jack calls an "ontology" ...
251451 - BINGO! ... yes, it seems I have agreed with Jack all along that we
251452 - need to define the OHS ontology, I just wasn't using the same words
251453 - that he was using.  Perhaps there are ontological description
251454 - languages out there, that can be viewed simply as service interface
251455 - description languages, that will satisfy everyone's needs for
251456 - describing the OHS in an inherently powerful and flexible and
251457 - extensible fashion. ref DRT 1 SF3H
251459 -  ..
251460 - That's what I think should be the focus right now.
251462 -      ..
251463 -     Ontology Requires Tools to Support Process
251464 -
251465 -     This seems like a stretch.  On 000221 Ontology is defined by one
251466 -     authority as derived from the philosophical inquiry into the
251467 -     nature of "existence." ref SDS 9 2622
251468 -
251469 -     In the context of "existence" the services of a software program
251470 -     are set out, or listed, in an ontology.  However, the critical
251471 -     correlation between "ontology" and the project is that we need to
251472 -     design technology that facilitates creation and maintenance of the
251473 -     ontology process, as one of the services, as Jack seemed to
251474 -     propose on 000623. ref SDS 26 2915
251475 -
251476 -
251477 -
251478 -
251479 -
251480 -
251481 -
2515 -