Date: Sun, 6 Oct 85 10:55 EST To: irdis at vpi Subject: IRList Digest V1 #13 IRList Digest Friday, 4 Oct 1985 Volume 1 : Issue 13 Today's Topics: Query - Overlap of IRList and AIList - Books in Print, and Expert Searching Announcement - PCE: Prolog system with C interface - ECRC pipe based C and Prolog interactive graphics - Access to tech report lists Article - Classification scheme for computers and Medicine ---------------------------------------------------------------------- From: Ave decus virginum! Date: Monday, 16 Sep 1985 08:03:51-PDT Subject: Extraction from AIList Digest It occurred to me to wonder what percentage of the IRList Digest readership also reads AIList Digest. I bring this up because of the amount of material you are copying from there for inclusion in IRList. It may be that most of your readers, like me, have already seen it. Do you think a poll to determine reader preference on this subject would be worthwhile? -- Roger Goun [I would welcome additional comments! Recently, AIList has been publishing excerpts from IRList too. I will try to avoid duplication but feel an obligation to select out items of particular interest. I expect that IRList readers and others will gradually submit more directly to IRList, so probably this situation will take care of itself. - Ed] ARPA: goun%cadlac.DEC@decwrl.ARPA UUCP: {allegra, decvax, ihnp4, ucbvax}!decwrl!dec-rhea!dec-cadlac!goun USPS: Digital Equipment Corp., APO-1/B4 100 Minuteman Road; Andover, MA 01810-1098 Tel: (617) 689-1675 ------------------------------ Date: Mon, 9 Sep 85 10:42 PDT From: RGARRETT%LAJ.SAINET.MFENET@LLL-MFE.ARPA Subject: Books-in-print database [Copied from PROLOG Digest Wed, 25 Sep 1985 Volume 3 : Issue 38 and a followup to msg in IRList Issue 10. - Ed] I assume you are familiar with "Books in Print" , the multi-volume listing of most of the books currently in print in the USA. I would like something similar but on magnetic media;i.e., mag tape and hopefully cheap. The purpose of this is to serve as the foundation for an expert system retrieval system to be written in (what else) PROLOG. Since this is both an experimental system (how many other kinds of expert systems are there?) and done as a graduate student, I am only interested in public domain or very low cost sources. I am already familiar with commercial systems such as DIALOG and with IRList. I hope this answers your questions, but if something is still unclear, just drop me a note. -- Randy Garrett ------------------------------ Date: Sun, 18 Aug 85 22:43:03 +0200 From: Anjo@seismo.CSS.GOV Subject: Building Large Systems [Copied from PROLOG Digest Mon, 26 Aug 1985 Volume 3 : Issue 37 If anyone has an address that works for Anjo, please let us know! - Ed] We have had a similar problem with developing a window system with a large number of utilities on top of Prolog. As the window system should have a fast user interface (responding to mouse clicks immediately), Prolog itself is not the most appropriate language to use. Our solution is implement the user interface and all the windowing stuff in C, along with text-editors, graphics editors, the mouse-manager etc. (at the moment this is about 300+ pages of C source code). This package is called PCE. Obviously the Prolog programmer wants full access to this package, he wants to create windows, graphical representations of knowledge inside his Prolog application and get mouse clicks if he needs them. This calls for bi-directional interface between PCE and Prolog. Our solution for this problem is to add a small number of predicates to Prolog that implement object orientedness, and a few functions that can asserted information available in PCE in the Prolog data-base (total source code of these functions is about 15 pages C). The advantages of this approach (in our case) are that the performance of the user interface doesn't depend on the performance of the Prolog interpreter, so all I/O functions are as fast as C can do it. The small interface assures that PCE can be modified without also needing to change part in the interface. For example if we decide to create another lay-out for a window only PCE needs to be changed, while both the interface between Prolog and PCE, and the Prolog applications remain unchanged. Whether an approach like this is also feasible for your problem depends, I think, on how well you succeed in keeping the interface between Prolog and the "Data Base System (DBS)" simple. From a software engineering point of view the saying "small is beautiful" certainly applies here. I think that it is possible to build an object oriented shell around a DBS, in that case the approach we have used becomes possible. A dangerous approach is to add predicates to Prolog for each operation you need, before long the interface will be large and porting it to another implementation of Prolog will for sure give problems. If we need to port PCE Prolog to another implementation only 15 pages of C-code needs to be rewritten, which is acceptable. The Prolog implementation we use is C-Prolog 1.5 with some local additions. If you would like to have more information or technical details (the predicates used for instance) let me now it. Greetings, -- Anjo Anjewierden ------------------------------ Date: Wed, 28 Aug 85 09:06:26 -0200 From: David McKelvie Subject: User Interfaces - Building Large Systems [Copied from PROLOG Digest Wed, 25 Sep 1985 Volume 3 : Issue 38 This refers to message above by A. Anjewierden. - Ed] We, the ECRC Man-machine interaction group, have had similar problems with the slowness of Prolog interpreters for handling interactive graphics, and have come up with a similar solution. We have split off the user interface part into a seperate process (we are using UNIX) and communicate to Prolog via a pipe, rather than a direct connection to the Prolog database as you seem to have. However we are having problems in defining what sort of interface there should be between the UI and Prolog. Therefore, we would be rather interested in the technical details of your interface, in particular the Prolog predicates you have defined, and what you mean by 'object orientedness' ( a horrible term for a good idea). Does this allow a more declarative than imperative way of defining pictures from Prolog? Thank you -- David Mckelvie (ECRC stands for European Computer-Industry Research Centre, a centre funded by European computer companies, mainly doing work on Logic programming and Knowledge bases. A sort of miniature version of ICOT or MCC ) ------------------------------ From: Laurence Leff Date: Fri, 27 Sep 85 13:38:21 cdt I have volunteered to organize an electronic mechanism for the distribution of technical report lists from Universities and R&D labs. Some (and hopefully all) of the people producing technical reports would send a copy of the list to me. I would then send these to a moderated group on USENET as well as a mailing list for those sites on the INTERNET who do not get news (ARPANET, CSNET, etc.). I need two things from you: 1) if your organization prepares technical reports and sends them out to interested parties (perhaps for a fee), please arrange to have electronically readable copy of your lists sent to trlist%smu@csnet-relay. 2) if people at your organization would like to receive lists of tech reports produced by universities and R&D labs, please provide me an electronic address to send them to (if you are not on USENET). Send such administrative mail to trlist-request%smu@ csnet-relay. Some frequently asked questions: 1. What are the advantages of sending my lists to you? a. Most of the people to whom you are sending printed lists will be receiving this list, either through the INTERNET as a mailing list or as a moderated news group on the USENET distributed bulletin board system. Thus you can save the postage and printing costs in mailing these lists. I would be happy to provide you with a list of institutions receiving this list as a mailing list as well as those institutions on USENET who would be receiving it that way. You can use this to prune the mailing list you use to send out printed copies of your technical report lists. b. Many people at the Universities are not aware of technical report lists. I have been sending out lists of AI tech reports to the AIList, an electronic newsletter on AI, for some time. Every time I do so, my electronic mailbox fills up with requests on how to obtain the tech reports. Many of these requests come from the most prestigious AI organizations in the country. c. Many companies, particularly those on the USENET, would not otherwise be aware of your research. There are hundreds of small companies on USENET who have no other access to the wealth of information represented by University and other tech reports. 2. What is a technical report? Most universities and big company R&D labs publish reports about their research. Some are higly research oriented (like new results in automata theory). Others are manuals for their public domain software or tutorials. For example NASA/Ames published a tutorial on SETUID programs under UNIX. These lists are currently sent out by mail to other schools and R&D labs. Some of the technical reports will later get turned into journal articles while other items will never be more formally published. Thus looking at these lists would give you information on new research results before they would appear in journals or would let you know of material you would not otherwise be aware of. 3. What format should the tech report lists be in? Please see to it that there is some info indicating how people can order the tech reports (whether sending you a check to cover costs, requests via electronic mail or the reports can be electronically available for Arpanet FTP transfer). If you are already producing the list in some format, feel free to use that format. If you are preparing the list just for this purpose, I would prefer that you use the input format for bib/refer, a common bibliography tool. This way people can dump the lists into a file on their machine and be able to do keyword searches. Also bib/refer will automatically include and format references in documents to be formatted or typeset. However, I would prefer the material in some weird format than not to have it at all! For those not familiar with bib/refer, here is a brief tutorial. Each report or other item should be a sequence of records which are not separated by blank lines. Each report should be separated by the others by one or more blank lines. Each report entry consists of a label consisting of a % followed by a capital letter and then a space. Then include the information. If the information for a field (such as an abstract) requires more than one line, just continue the field on a new line with no initial space. The labels needed for tech reports are: %A Author's name (this field should be repeated for each author). %T Title of report %R report number %I issuer, this will be the name of your institution. This may be ommited if implied by the report number %C City where published (not essential) %D Date of publication %X Abstract Here is an example of some tech report listings in the appropriate format: %A D. Rozenshtein %A J. Chomicki %T Unifying the Use and Evolution of Database Systems: A Case Study in PROLOG %R LCSR-TR-68 %I Laboratory for Computer Science Research, Rutgers University %K frame control %A C. V. Srinivasan %T CK-LOG, A Calculus for Knowledge Processing in Logic %R DCS-TR-153 %I Laboratory for Computer Research, Rutgers University %K MDS 4. I already have exchange agreements with other Universities. How does this affect them? The only change would be how the information on what technical reports you have for them to request gets transferred. Instead of them receiving a piece of paper by U. S. Mail, they would look at the appropriate notes group (if this is a USENET site) or at the item received in the mail, request the reports they want and send the request to you. You would probably request that the free technical report order came from a specific person or account in case some student seeing the list decided to order the tech reports. You should do that with the printed lists anyway since at some schools, technical report lists are frequently left around for graduate students and faculty to look at and check the ones they want. Any person could send in the form themselves if they chose. 5. I need to charge for my tech reports to cover costs. Fine. Just include the prices for your reports next to each report (you can use the %X field for that too). At the beginning of the list you send me, state where checks should be sent and to whom they should be made payable. 6. What about non-CS reports? I am happy to handle reports for other departments. If the volume of non-CS reports becomes significant, I will split the list into tr-cs, tr-math, tr-ee etc. I would suspect that the majority of the people receiving this list would be CS researchers since CS departments are quick to join networks, etc. However, some CS researchers (myself included) are working in applications of computers and would like to receive information in those areas as well. 7. I am already on USENET. What should I do? I anticipate a USENET moderated group in a time frame of one to two weeks which will contain the same information as the technical report lists. If you indicate that you will get the information via USENET, I will remove your name when the list is established. If you want to wait a week or two to see if the list comes up, that is OK too. I can send back copies of the TR Lists that get sent out in the first few batches of the mailing. I will also send out on the USENET group, everything that got sent out in the mailing list so you won't miss anything either way. 8. I am on Arpanet, BITNET, etc. I can get to Arpanet sites through csnet-relay so there is no problem there. Otherwise, send me your address as best you know it. I will get through to you if at all possible. ------------------------------ From: Roy Rada CSB Date: Tue, 24 Sep 85 14:16:10 edt Which Way for a Classification Scheme for Computers and Medicine Roy Rada The National Library of Medicine supports an extensive collection of online indexed document citations for the biomedical field. The indexing scheme, although one of the first of its kind, remains one of the most sophisticated in everyday usage. The 14,000 terms of the Medical Subject Headings (MeSH) are organized in a hierarchy of "is-a" relations that constitute a very sim- plified knowledge-base of the biomedical literature. The MeSH classification of articles seems to provide better support of retrieval than the also popular string-searching strategies of some document retrieval systems (see D Blair and M Maron "An Evaluation of Retrieval Effectiveness for a Full-Text Document-Retrieval System" in Comm ACM, March 1985, p 289-299). In the inter- section of computers and medicine MeSH is understandably sketchy. But as the progress in medicine becomes more connected to high-technology the need for a richer MeSH classification of computer-related medical work increases. A com- mittee of scholars could convene, study MeSH, and propose amendments that would refine its coverage of computer-type material. Alternatively, one could explore algorithms for merging the better parts of MeSH's coverage of comput- ing with the better parts of a classification scheme that is richer in the computing domain. To this end, this article presents a portion of MeSH relat- ing to computing and a portion of the ACM classification scheme for computing literature. At the end of this article are this month's listing in the Na- tional Library of Medicine computer of articles whose main index terms includ- ed those from the computer-branch of MeSH. If you have any suggestions about ways to get the best of both of these classification schemes, please send a note to the Editor of the SIGBIO Newsletter. While addressing the problem of improving classifications, this article primarily serves as a source of infor- mation about recent articles and as a listing of parts of classification schemes that might be of interest to SIGBIO members--thus the length of the remainder of this piece. The MeSH components here include on each line the MeSH number followed by the MeSH term. A term x is "an instance of" another term y, when the number of y is a prefix of the number for x. First some parts of the anatomy section are given to show the nature of MeSH in normal biomedical areas. Then part of the Information Science component of MeSH is given. A01.378 Extremities A01.378.209 Arm A01.378.209.235 Elbow A01.378.209.350 Forearm A01.378.209.455 Hand A01.378.209.455.430 Fingers A01.378.209.455.430.705 Thumb A01.378.209.749 Shoulder A01.378.209.906 Wrist A01.378.592 Leg A01.378.592.116 Ankle A01.378.592.350 Foot A01.378.592.350.377 Heel A01.378.592.350.792 Toes A01.378.592.350.792.456 Hallux L01 Information Science (Non Mesh) L01.040 Book Collecting L01.080 Chronology L01.100 Classification L01.143 Communication L01.143.050 Advertising L01.143.115 Animal Communication L01.143.230 Communication Barriers L01.143.283 Cybernetics L01.143.283.425 Feedback L01.143.320 Diffusion of Innovation L01.143.506 Language a section has been here skipped L01.210 Computers L01.210.100 Analog-Digital Conversion L01.210.190 Computer Programs L01.210.230 Computers, Analog L01.210.260 Computers, Hybrid L01.210.310 Diagnosis, Computer Assisted L01.210.550 Microcomputers L01.210.580 Minicomputers L01.210.690 Online Systems L01.210.690.250 Computer Assisted Instruction L01.210.690.630 MEDLARS-MEDLINE Information System L01.240 Copying Processes Following is a part of the ACM classification scheme that is used in indexing articles for ACM. h.3 information storage and retrieval h.3.0 general h.3.1 content analysis and indexing h.3.1.1 abstracting methods h.3.1.2 dictionaries h.3.1.3 indexing methods h.3.1.4 linguistic processing h.3.1.5 thesauruses h.3.2 information storage h.3.2.1 file organization h.3.2.2 record classification h.3.3 information search and retrieval h.3.3.1 clustering h.3.3.2 query formulation h.3.3.3 retrieval models h.3.3.4 search process h.3.3.5 selection process h.3.4 systems and software h.3.4.1 current awareness systems h.3.4.2 information networks h.3.4.3 question-answering systems [Note: Roy Rada can be contacted directly about this but replies to IRList will be collected and issued together when available. - Ed] ------------------------------ END OF IRList Digest ********************