blog:Try Harder_1

Status

active, expires in 1,636,568 blocks (~9,352 days)

Owner

EcBxaftcsQ4GNcsx5bUY2J3hmSZZDNdBQR

Expires at

block 2454350

Last change

29172d146727…b146728452db

Value

What it should have been, we blew it humanity\r\n\r\nhttps://www.w3.org/History/1989/proposal.html\r\n\r\nInformation Management: A Proposal\r\nTim Berners-Lee, CERN\r\nMarch 1989, May 1990\r\nThis proposal concerns the management of general information about accelerators and experiments at CERN. It discusses the problems of loss of information about complex evolving systems and derives a solution based on a distributed hypertext system.\r\n\r\nA circles and arrows diagram relating concepts discussed in the paper\r\n\r\nOverview\r\nMany of the discussions of the future at CERN and the LHC era end with the question - ªYes, but how will we ever keep track of such a large project?º This proposal provides an answer to such questions. Firstly, it discusses the problem of information access at CERN. Then, it introduces the idea of linked information systems, and compares them with less flexible ways of finding information.\r\n\r\nIt then summarises my short experience with non-linear text systems known as ªhypertextº, describes what CERN needs from such a system, and what industry may provide. Finally, it suggests steps we should take to involve ourselves with hypertext now, so that individually and collectively we may understand what we are creating.\r\n\r\nLosing Information at CERN\r\nCERN is a wonderful organisation. It involves several thousand people, many of them very creative, all working toward common goals. Although they are nominally organised into a hierarchical management structure,this does not constrain the way people will communicate, and share information, equipment and software across groups.\r\n\r\nThe actual observed working structure of the organisation is a multiply connected \"web\" whose interconnections evolve with time. In this environment, a new person arriving, or someone taking on a new task, is normally given a few hints as to who would be useful people to talk to. Information about what facilities exist and how to find out about them travels in the corridor gossip and occasional newsletters, and the details about what is required to be done spread in a similar way. All things considered, the result is remarkably successful, despite occasional misunderstandings and duplicated effort.\r\n\r\nA problem, however, is the high turnover of people. When two years is a typical length of stay, information is constantly being lost. The introduction of the new people demands a fair amount of their time and that of others before they have any idea of what goes on. The technical details of past projects are sometimes lost forever, or only recovered after a detective investigation in an emergency. Often, the information has been recorded, it just cannot be found.\r\n\r\nIf a CERN experiment were a static once-only development, all the information could be written in a big book. As it is, CERN is constantly changing as new ideas are produced, as new technology becomes available, and in order to get around unforeseen technical problems. When a change is necessary, it normally affects only a small part of the organisation. A local reason arises for changing a part of the experiment or detector. At this point, one has to dig around to find out what other parts and people will be affected. Keeping a book up to date becomes impractical, and the structure of the book needs to be constantly revised.\r\n\r\nThe sort of information we are discussing answers, for example, questions like\r\n\r\nWhere is this module used?\r\nWho wrote this code? Where does he work?\r\nWhat documents exist about that concept?\r\nWhich laboratories are included in that project?\r\nWhich systems depend on this device?\r\nWhat documents refer to this one?\r\nThe problems of information loss may be particularly acute at CERN, but in this case (as in certain others), CERN is a model in miniature of the rest of world in a few years time. CERN meets now some problems which the rest of the world will have to face soon. In 10 years, there may be many commercial solutions to the problems above, while today we need something to allow us to continue.\r\n\r\nLinked information systems\r\nIn providing a system for manipulating this sort of information, the hope would be to allow a pool of information to develop which could grow and evolve with the organisation and the projects it describes. For this to be possible, the method of storage must not place its own restraints on the information. This is why a \"web\" of notes with links (like references) between them is far more useful than a fixed hierarchical system. When describing a complex system, many people resort to diagrams with circles and arrows. Circles and arrows leave one free to describe the interrelationships between things in a way that tables, for example, do not. The system we need is like a diagram of circles and arrows, where circles and arrows can stand for anything.\r\n\r\nWe can call the circles nodes, and the arrows links. Suppose each node is like a small note, summary article, or comment. I'm not over concerned here with whether it has text or graphics or both. Ideally, it represents or describes one particular person or object. Examples of nodes can be\r\n\r\nPeople\r\nSoftware modules\r\nGroups of people\r\nProjects\r\nConcepts\r\nDocuments\r\nTypes of hardware\r\nSpecific hardware objects\r\nThe arrows which links circle A to circle B can mean, for example, that A...\r\n\r\ndepends on B\r\nis part of B\r\nmade B\r\nrefers to B\r\nuses B\r\nis an example of B\r\nThese circles and arrows, nodes and links, have different significance in various sorts of conventional diagrams:\r\n\r\nDiagram\tNodes are\tArrows mean\r\nFamily tree\tPeople\t\"Is parent of\"\r\nDataflow diagram\tSoftware modules\"\tPasses data to\"\r\nDependency\tModule\t\"Depends on\"\r\nPERT chart\tTasks\t\"Must be done before\"\r\nOrganisational chart\tPeople\t\"Reports to\"\r\nThe system must allow any sort of information to be entered. Another person must be able to find the information, sometimes without knowing what he is looking for.\r\n\r\nIn practice, it is useful for the system to be aware of the generic types of the links between items (dependences, for example), and the types of nodes (people, things, documents..) without imposing any limitations.\r\n\r\nThe problem with trees\r\nMany systems are organised hierarchically. The CERNDOC documentation system is an example, as is the Unix file system, and the VMS/HELP system. A tree has the practical advantage of giving every node a unique name. However, it does not allow the system to model the real world. For example, in a hierarchical HELP system such as VMS/HELP, one often gets to a leaf on a tree such as\r\n\r\n HELP COMPILER SOURCE_FORMAT PRAGMAS DEFAULTS\r\nonly to find a reference to another leaf: \"Please see\r\n\r\n HELP COMPILER COMMAND OPTIONS DEFAULTS PRAGMAS\"\r\nand it is necessary to leave the system and re-enter it. What was needed was a link from one node to another, because in this case the information was not naturally organised into a tree.\r\n\r\nAnother example of a tree-structured system is the uucp News system (try 'rn' under Unix). This is a hierarchical system of discussions (\"newsgroups\") each containing articles contributed by many people. It is a very useful method of pooling expertise, but suffers from the inflexibility of a tree. Typically, a discussion under one newsgroup will develop into a different topic, at which point it ought to be in a different part of the tree. (See Fig 1).\r\n\r\nFrom mcvax!uunet!pyrdc!pyrnj!rutgers!bellcore!geppetto!duncan Thu Mar...\r\nArticle 93 of alt.hypertext:\r\nPath: cernvax!mcvax!uunet!pyrdc!pyrnj!rutgers!bellcore!geppetto!duncan\r\n>From: duncan@geppetto.ctt.bellcore.com (Scott Duncan)\r\nNewsgroups: alt.hypertext\r\nSubject: Re: Threat to free information networks\r\nMessage-ID: <14646@bellcore.bellcore.com>\r\nDate: 10 Mar 89 21:00:44 GMT\r\nReferences: <1784.2416BB47@isishq.FIDONET.ORG> <3437@uhccux.uhcc...\r\nSender: news@bellcore.bellcore.com\r\nReply-To: duncan@ctt.bellcore.com (Scott Duncan)\r\nOrganization: Computer Technology Transfer, Bellcore\r\nLines: 18\r\n\r\nDoug Thompson has written what I felt was a thoughtful article on\r\ncensorship -- my acceptance or rejection of its points is not\r\nparticularly germane to this posting, however.\r\n\r\nIn reply Greg Lee has somewhat tersely objected.\r\n\r\nMy question (and reason for this posting) is to ask where we might\r\nlogically take this subject for more discussion. Somehow alt.hypertext\r\ndoes not seem to be the proper place.\r\n\r\nWould people feel it appropriate to move to alt.individualism or even\r\none of the soc groups. I am not so much concerned with the specific\r\nissue of censorship of rec.humor.funny, but the views presented in\r\nGreg's article.\r\n\r\nSpeaking only for myself, of course, I am...\r\nScott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)\r\n (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ...)\r\n (201-699-3910 (w) 201-463-3683 (h))\r\nFig 1. An article in the UUCP News scheme.\r\nThe Subject field allows notes on the same topic to be linked together within a \"newsgroup\". The name of the newsgroup (alt.hypertext) is a hierarchical name. This particular note is expresses a problem with the strict tree structure of the scheme: this discussion is related to several areas. Note that the \"References\", \"From\" and \"Subject\" fields can all be used to generate links.\r\n\r\nThe problem with keywords\r\nKeywords are a common method of accessing data for which one does not have the exact coordinates. The usual problem with keywords, however, is that two people never chose the same keywords. The keywords then become useful only to people who already know the application well.\r\n\r\nPractical keyword systems (such as that of VAX/NOTES for example) require keywords to be registered. This is already a step in the right direction. A linked system takes this to the next logical step. Keywords can be nodes which stand for a concept. A keyword node is then no different from any other node. One can link documents, etc., to keywords. One can then find keywords by finding any node to which they are related. In this way, documents on similar topics are indirectly linked, through their key concepts. A keyword search then becomes a search starting from a small number of named nodes, and finding nodes which are close to all of them.\r\n\r\nIt was for these reasons that I first made a small linked information system, not realising that a term had already been coined for the idea: \"hypertext\".\r\n\r\nA solution: Hypertext\r\nPersonal Experience with Hypertext\r\nIn 1980, I wrote a program for keeping track of software with which I was involved in the PS control system. Called Enquire, it allowed one to store snippets of information, and to link related pieces together in any way. To find information, one progressed via the links from one sheet to another, rather like in the old computer game \"adventure\". I used this for my personal record of people and modules. It was similar to the application Hypercard produced more recently by Apple for the Macintosh. A difference was that Enquire, although lacking the fancy graphics, ran on a multiuser system, and allowed many people to access the same data.\r\n\r\nDocumentation of the RPC project (concept)\r\n\r\n\r\n Most of the documentation is available on VMS, with the two\r\n principle manuals being stored in the CERNDOC system.\r\n\r\n 1) includes: The VAX/NOTES conference VXCERN::RPC\r\n 2) includes: Test and Example suite\r\n 3) includes: RPC BUG LISTS\r\n 4) includes: RPC System: Implementation Guide\r\n Information for maintenance, porting, etc.\r\n 5) includes: Suggested Development Strategy for RPC Applications\r\n 6) includes: \"Notes on RPC\", Draft 1, 20 feb 86\r\n 7) includes: \"Notes on Proposed RPC Development\" 18 Feb 86\r\n 8) includes: RPC User Manual\r\n How to build and run a distributed system.\r\n 9) includes: Draft Specifications and Implementation Notes\r\n 10) includes: The RPC HELP facility\r\n 11) describes: THE REMOTE PROCEDURE CALL PROJECT in DD/OC\r\n\r\n\r\n\r\n\r\n\r\n Help Display Select Back Quit Mark Goto_mark Link Add Edit\r\nFig 2. A screen in an Enquire scheme.\r\nThis example is basically a list, so the list of links is more important than the text on the node itself. Note that each link has a type (\"includes\" for example) and may also have comment associated with it. (The bottom line is a menu bar.)\r\n\r\nSoon after my re-arrival at CERN in the DD division, I found that the environment was similar to that in PS, and I missed Enquire. I therefore produced a version for the VMS, and have used it to keep track of projects, people, groups, experiments, software modules and hardware devices with which I have worked. I have found it personally very useful. I have made no effort to make it suitable for general consumption, but have found that a few people have successfully used it to browse through the projects and find out all sorts of things of their own accord.\r\n\r\nHot spots\r\nMeanwhile, several programs have been made exploring these ideas, both commercially and academically. Most of them use \"hot spots\" in documents, like icons, or highlighted phrases, as sensitive areas. touching a hot spot with a mouse brings up the relevant information, or expands the text on the screen to include it. Imagine, then, the references in this document, all being associated with the network address of the thing to which they referred, so that while reading this document you could skip to them with a click of the mouse.\r\n\r\n\"Hypertext\" is a term coined in the 1950s by Ted Nelson [...], which has become popular for these systems, although it is used to embrace two different ideas. One idea (which is relevant to this problem) is the concept: \"Hypertext\": Human-readable information linked together in an unconstrained way.\r\n\r\nThe other idea, which is independent and largely a question of technology and time, is of multimedia documents which include graphics, speech and video. I will not discuss this latter aspect further here, although I will use the word \"Hypermedia\" to indicate that one is not bound to text.\r\n\r\nIt has been difficult to assess the effect of a large hypermedia system on an organisation, often because these systems never had seriously large-scale use. For this reason, we require large amounts of existing information should be accessible using any new information management system.\r\n\r\nCERN Requirements\r\nTo be a practical system in the CERN environment, there are a number of clear practical requirements.\r\n\r\nRemote access across networks.\r\nCERN is distributed, and access from remote machines is essential.\r\n\r\nHeterogeneity\r\nAccess is required to the same data from different types of system (VM/CMS, Macintosh, VAX/VMS, Unix)\r\n\r\nNon-Centralisation\r\nInformation systems start small and grow. They also start isolated and then merge. A new system must allow existing systems to be linked together without requiring any central control or coordination.\r\n\r\nAccess to existing data\r\nIf we provide access to existing databases as though they were in hypertext form, the system will get off the ground quicker. This is discussed further below.\r\n\r\nPrivate links\r\nOne must be able to add one's own private links to and from public information. One must also be able to annotate links, as well as nodes, privately.\r\n\r\nBells and Whistles\r\nStorage of ASCII text, and display on 24x80 screens, is in the short term sufficient, and essential. Addition of graphics would be an optional extra with very much less penetration for the moment.\r\n\r\nData analysis\r\nAn intriguing possibility, given a large hypertext database with typed links, is that it allows some degree of automatic analysis. It is possible to search, for example, for anomalies such as undocumented software or divisions which contain no people. It is possible to generate lists of people or devices for other purposes, such as mailing lists of people to be informed of changes. It is also possible to look at the topology of an organisation or a project, and draw conclusions about how it should be managed, and how it could evolve. This is particularly useful when the database becomes very large, and groups of projects, for example, so interwoven as to make it difficult to see the wood for the trees.\r\n\r\nIn a complex place like CERN, it's not always obvious how to divide people into groups. Imagine making a large three-dimensional model, with people represented by little spheres, and strings between people who have something in common at work.\r\n\r\nNow imagine picking up the structure and shaking it, until you make some sense of the tangle: perhaps, you see tightly knit groups in some places, and in some places weak areas of communication spanned by only a few people. Perhaps a linked information system will allow us to see the real structure of the organisation in which we work.\r\n\r\nLive links\r\nThe data to which a link (or a hot spot) refers may be very static, or it may be temporary. In many cases at CERN information about the state of systems is changing all the time. Hypertext allows documents to be linked into \"live\" data so that every time the link is followed, the information is retrieved. If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide.\r\n\r\nNon requirements\r\nDiscussions on Hypertext have sometimes tackled the problem of copyright enforcement and data security. These are of secondary importance at CERN, where information exchange is still more important than secrecy. Authorisation and accounting systems for hypertext could conceivably be designed which are very sophisticated, but they are not proposed here.\r\n\r\nIn cases where reference must be made to data which is in fact protected, existing file protection systems should be sufficient.\r\n\r\nSpecific Applications\r\nThe following are three examples of specific places in which the proposed system would be immediately useful. There are many others.\r\n\r\nDevelopment

History