Copy Link
Add to Bookmark
Report

IRList Digest Volume 1 Number 13

eZine's profile picture
Published in 
IRList Digest
 · 1 year ago

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! <goun%cadlac.DEC@DECWRL>
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 <mcvax!unido!ecrcvax!david@seismo.CSS.GOV>
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 <leff@SMU>
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 <rada@NLM-MCS>
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
********************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT