Search (39 results, page 1 of 2)

  • × language_ss:"e"
  • × theme_ss:"Datenfernübertragung"
  • × type_ss:"a"
  1. Deussen, N.: Sogar der Mars könnte bald eine virutelle Heimat bekommen : Gut 4,2 Milliarden sind nicht genug: Die sechste Version des Internet-Protokolls schafft viele zusätzliche Online-Adressen (2001) 0.00 
    0.003509638 = product of:
  0.021057827 = sum of:
    0.0031667221 = weight(_text_:in in 5729) [ClassicSimilarity], result of:
      0.0031667221 = score(doc=5729,freq=16.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.10626988 = fieldWeight in 5729, product of:
          4.0 = tf(freq=16.0), with freq of:
            16.0 = termFreq=16.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.01953125 = fieldNorm(doc=5729)
    0.015395259 = weight(_text_:der in 5729) [ClassicSimilarity], result of:
      0.015395259 = score(doc=5729,freq=52.0), product of:
        0.048934754 = queryWeight, product of:
          2.2337668 = idf(docFreq=12875, maxDocs=44218)
          0.021906832 = queryNorm
        0.31460786 = fieldWeight in 5729, product of:
          7.2111025 = tf(freq=52.0), with freq of:
            52.0 = termFreq=52.0
          2.2337668 = idf(docFreq=12875, maxDocs=44218)
          0.01953125 = fieldNorm(doc=5729)
    0.0024958462 = product of:
      0.0074875387 = sum of:
        0.0074875387 = weight(_text_:29 in 5729) [ClassicSimilarity], result of:
          0.0074875387 = score(doc=5729,freq=2.0), product of:
            0.077061385 = queryWeight, product of:
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.021906832 = queryNorm
            0.097163305 = fieldWeight in 5729, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.01953125 = fieldNorm(doc=5729)
      0.33333334 = coord(1/3)
  0.16666667 = coord(3/18)
    Abstract
    In der Virtualität wird's eng. Die Möglichkeiten des Scheinbaren sind anscheinend ausgereizt. Es mangelt bald an InternetAdressen. Wenn WhirIpools und Wasclunaschinen ihren eigenen Zugang zum Internet brauchen, wird der Vorrat an Kennzahlen knapp. Um dem drohenden Mangel zu begegnen, wird seit Jahren an einer überarbeiteten Fassung des Internet-Protokolls (IP) gebastelt. Doch die Neuauflage hat bis auf ein paar Testläufe - bisher ihren Weg ins Netz noch nicht gefunden. Für Aufregung sorgte sie dennoch bereits: wegen Datenschutzproblemen. Für die Kommunikation zwischen Computern im Internet gibt es eine Art Knigge. Die protokollarische Vorschrift legt fest; wie die Rechner Daten untereinander austauschen. Doch zuvor brauchen die Maschinen Namen (wie www.fr-aktuell.de) und Anschriften (hier: 194.175.173.20), damit sie sich einander vorstellen (Shake Hands) und später Daten schicken können. Vergeben werden die Bezeichnungen von der Internet Corporation for Assigned Names and Numbers Icann). Den ersten Vorschlag für eine einheitliche Übergaberegelung machten Bob Kahn und Vint Cerf im Jahr 1974. Damals versuchten im inzwischen legendären, militärisch genutzten Arpanet kaum tausend Großrechner an etwa 250 Standorten miteinander zu kommunizieren. Um Ordnung in das Sprachengewirr der verschiedenen Bautypen zu bringen, mussten Regeln her. Die Idee entwickelte sich zum Protokoll, das nach Informatik-Manier mit dem Kürzel TCP/IP belegt wurde. Mit etwa 100000 angeschlossenen Computern wurde das Netz 1983 zivil - und TCP/IP zum offiziellen Standard. Derzeit regelt die vierte Version des Internet-Protokolls (IPv4) den Bit-Transport. Die Adresse wird jedem Datenpaket vorangestellt. Sie besteht aus Ziffern und ist exakt 32 Bit lang. Daraus ergeben sich mehr als 4,2 Milliarden Zahlenkombinationen. Genug für einen Globus, auf dem erst kürzlich der sechsmilliardste Erdenbürger das Licht der realen Welt erblickte - dachten die Computer-Operateure damals. Dann kam das World Wide Web.
    Der Geniestreich aus dem Europäischen Labor für Teilchenphysik (Cern) in Genf machte aus dem Wissenschaftsnetz ein Massenmedium. Zudem erfuhr die elektronische Post einen Aufschwung. Das Wachstum der Netze sprengt alle Erwartungen", resümiert Klaus Birkenbihl vom InformatikForschungszentrum GMI). Jede Web-Site, jede E-Mail-Box, jeder Computer, der per Standleitung online ist, braucht eine eindeutige Identifizierung. Die Schätzungen, wie viele IPv4-Adressen noch frei sind, schwanken zwischen 40 und zehn Prozent. Der Verbrauch jedenfalls steigt rasant: Die Anzahl der WebSites steuert derzeit auf eine Milliarde zu, weit mehr Netznummern gehen bereits für E-Mail-Anschriften drauf. Den Adressraum weiter ausschöpfen werden demnächst die intelligenten Haushaltsgeräte. Der Laden an der Ecke will wissen, welcher Kühlschrank die Milch bestellt hat, die Videozentrale braucht für das Überspielen des Films die Kennung des PC-Recorders, der Computer des Installateurs benötigt die IP-Anschrift der Heizungsanlage für die Fernwartung. Handys, die später Nachrichten übers Internet schicken, und Internet-Telefonie gehen möglicherweise leer aus. Doch bevor Internet-Adressen zur heiß begehrten Schieberware werden, soll ein neues Adresssystern mit mehr Möglichkeiten her. Schon 1990 hatte sich die Internet Engineering Task Force (IETF) Gedanken über einen neues Internet-Protokoll mit einem größeren Adressangebot gemacht. Im IETF kümmern sich Forscher, Soft- und HardwareIngenieure um die fortlaufende Verbesserung von Architektur und Arbeit des Netz werks. Eine ihrer Arbeitsgruppen prognostizierte, der IPv4-Vorrat gehe 2005 zu Ende. Fünf Jahre dauerte es, dann waren sich alle Internet-Gremien einig: Eine neue Protokollversion, IPv6, muss her. Dann passierte weiter nichts. Endlich verkündete 1999 Josh Elliot von der Icann, ab sofort würden neue Anschriften verteilt. Ein historischer Moment", freute er sich.
    Der neue 128-Bit-Header treibt die Möglichkeiten ins Astronomische: 3,4 mal zehn hoch 38 Adressen, eine 3,4 mit 38 Nullen. -Das IPv6-Forum zerhackte den Zahlentrumm in anschauliche Stücke: Pro Quadratmillimeter Erdoberfläche stehen nun zirka 667 Billiarden, pro Mensch 6,5 mal zehn hoch 28 Adressen, bereit." Eine Billiarde bringt es immerhin auf respektable 15 Nullen. Schon kurz darauf ging ein Aufschrei durch die Netzgemeinde. Das neue Protokoll schrieb die weltweit eindeutigen Seriennummern bestimmter Netzwerkkarten auf den virtuellen Adressaufkleber. Die Ethernet-Adapter bewerkstelligen den Datentransport bei Computern, die über eine Standleitung, ein Koaxialkabel, dauernd online sind. Die Spur von Ethernet-Usern wäre damit leicht zu verfolgen gewesen, ihre Nutzerprofile, ihre Surfgewohnheiten einsehbar wie offene Bücher. Das Problem, ließ Icann nun wissen, sei behoben: Es gebe keine festen Kennzahlen mehr in den Adressköpfen. Bei jedem Hochfahren eines Rechners oder sogar noch öfter werden die Nummern neu durchgemischt", erläutert Hans Petter Dittler, stellvertretender Vorsitzender der deutschen Sektion der Internet Society. Das Betriebssystem Linux kann bereits mit dem IPv6 arbeiten. Microsoft will den Standard in das nächste Windows-Betriebssystem einbauen: "Wir denken, der vorgeschlagene Standard ist wichtig zum Schutz der Privatsphäre der Internet-Nutzer", sagt Jawad Khaki, Vizepräsident für Netzwerke. Seit einigen Tagen steht auf der Microsoft-Homepage eine Vorab-Version von lPv6 für Windows 2000 zum Herunterladen bereit. Geradezu euphorisch gibt sich Protokoll-Chef Vint Cerf. Mit IPv6 haben wir die Grundlage dafür", philosophierte der Internet-Daddy auf dem ersten lPv6-Kongress 1999 in Berlin, "das Internet von unserem Planeten über den Mars und die Asteroiden bis in den Weltraum hinaus auszudehnen." Doch im Internet-Alltag wird das alte Protokoll noch lange Vorrang haben. Grund sind handfeste Programmier-Probleme. Denn Software, die sich explizit auf die vierte IP-Version bezieht, muss umgeschrieben werden - etwa um mit den längeren Adressfeldern umgehen zu können. Hubert Martens vom Münchner Multinet Services befürchtet gar einen InternetCrash: "Das Jahr-2000-Problem war harmlos gegen das, was uns mit lPv6 droht."
    Source
    Frankfurter Rundschau. Nr.79 vom 3.4.2001, S.29
  2. Bayer, M.: ¬Die Werbeabteilung ist schneller : Das Internet aus der Steckdose - lange angekündigt - soll nun im Juli starten / schwierige technische Entwicklung (2001) 0.00 
    0.0019609262 = product of:
  0.017648336 = sum of:
    0.009661627 = weight(_text_:der in 3321) [ClassicSimilarity], result of:
      0.009661627 = score(doc=3321,freq=2.0), product of:
        0.048934754 = queryWeight, product of:
          2.2337668 = idf(docFreq=12875, maxDocs=44218)
          0.021906832 = queryNorm
        0.19743896 = fieldWeight in 3321, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.2337668 = idf(docFreq=12875, maxDocs=44218)
          0.0625 = fieldNorm(doc=3321)
    0.007986708 = product of:
      0.023960123 = sum of:
        0.023960123 = weight(_text_:29 in 3321) [ClassicSimilarity], result of:
          0.023960123 = score(doc=3321,freq=2.0), product of:
            0.077061385 = queryWeight, product of:
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.021906832 = queryNorm
            0.31092256 = fieldWeight in 3321, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.0625 = fieldNorm(doc=3321)
      0.33333334 = coord(1/3)
  0.11111111 = coord(2/18)
    Source
    Frankfurter Rundschau. Nr.79 vom 3.4.2001, S.29
  3. Reiss, L.K.; Merakos, L.F.: Performance analysis of an adaptive bandwidth reservation scheme for ATM virtual path traffic (1996) 0.00 
    0.0014503849 = product of:
  0.013053464 = sum of:
    0.0050667557 = weight(_text_:in in 4758) [ClassicSimilarity], result of:
      0.0050667557 = score(doc=4758,freq=4.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.17003182 = fieldWeight in 4758, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0625 = fieldNorm(doc=4758)
    0.007986708 = product of:
      0.023960123 = sum of:
        0.023960123 = weight(_text_:29 in 4758) [ClassicSimilarity], result of:
          0.023960123 = score(doc=4758,freq=2.0), product of:
            0.077061385 = queryWeight, product of:
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.021906832 = queryNorm
            0.31092256 = fieldWeight in 4758, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.0625 = fieldNorm(doc=4758)
      0.33333334 = coord(1/3)
  0.11111111 = coord(2/18)
    Abstract
    Adaptive, in-call, bandwidth reservation may be used to enhance bandwidth utilization in a policed asynchronous transfer mode (ATM) virtual path shared by traffic streams originated by many bursty sources. Presents a model, based on Markov-modulated sources and stochastic fluid methods, for performance analysis of the proposed mechanism. The model, corroborated by simulations, is used to study achievable bandwidth gain and the effects of feedback delay and competing reservation processes
    Date
    2. 8.1996 19:36:29
  4. Bradley, P.: Towards a common user interface (1995) 0.00 
    0.0012690867 = product of:
  0.01142178 = sum of:
    0.004433411 = weight(_text_:in in 3133) [ClassicSimilarity], result of:
      0.004433411 = score(doc=3133,freq=4.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.14877784 = fieldWeight in 3133, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0546875 = fieldNorm(doc=3133)
    0.006988369 = product of:
      0.020965107 = sum of:
        0.020965107 = weight(_text_:29 in 3133) [ClassicSimilarity], result of:
          0.020965107 = score(doc=3133,freq=2.0), product of:
            0.077061385 = queryWeight, product of:
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.021906832 = queryNorm
            0.27205724 = fieldWeight in 3133, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5176873 = idf(docFreq=3565, maxDocs=44218)
              0.0546875 = fieldNorm(doc=3133)
      0.33333334 = coord(1/3)
  0.11111111 = coord(2/18)
    Abstract
    Discusses the advantages and disadvantages of a common user interface to enable searching of all databases regardless of producer, supplier or location, such as local CD-ROM, or network. Explains client server architecture, the basic component of a common user interface and outlines current developments including the Z39.50 application layer protocol. A common user interface will result in greater synergy between information providers, technology providers, distributors and information professionals. It will also be able to search across the Internet and make that huge wealth of data much more available than it currently is. Predicts that a common user interface will be in operation by the turn of the century
    Date
    29. 1.1996 19:28:01
  5. Lazinger, S.S.; Peritz, B.C.: Reader use of a nationwide research library network : local OPAC vs. remote files (1991) 0.00 
    0.0012566947 = product of:
  0.011310252 = sum of:
    0.0053741056 = weight(_text_:in in 3013) [ClassicSimilarity], result of:
      0.0053741056 = score(doc=3013,freq=8.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.18034597 = fieldWeight in 3013, product of:
          2.828427 = tf(freq=8.0), with freq of:
            8.0 = termFreq=8.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.046875 = fieldNorm(doc=3013)
    0.0059361467 = product of:
      0.01780844 = sum of:
        0.01780844 = weight(_text_:22 in 3013) [ClassicSimilarity], result of:
          0.01780844 = score(doc=3013,freq=2.0), product of:
            0.076713994 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.021906832 = queryNorm
            0.23214069 = fieldWeight in 3013, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.046875 = fieldNorm(doc=3013)
      0.33333334 = coord(1/3)
  0.11111111 = coord(2/18)
    Abstract
    The primary objective of the present study was to exmine whether readers conducting bibliographic searches in ALEPH - Israel's research library network - tend to search only within the OPAC of the library within which they are working or whether they access the remote OPACs of other libraries. The ALEPH network has a dezentralized database. Therefore, it was possible to examine this question because each library has its own access code and each database can be searched separately. The data were collected by means of a one-page questionnaire lefr beside each terminal in the library of the Graduate School of Library and Archive Studies of the Hebrew University of Jerusalem during an entire academic years. results of analysis of the data collected in this survey are presented in 6 tables
    Date
    22. 2.1999 13:06:18
  6. Sloan, B.G.: Remote access : design implications for the online catalog (1991) 0.00 
    0.0011178222 = product of:
  0.0100604 = sum of:
    0.0031348949 = weight(_text_:in in 3696) [ClassicSimilarity], result of:
      0.0031348949 = score(doc=3696,freq=2.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.10520181 = fieldWeight in 3696, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0546875 = fieldNorm(doc=3696)
    0.0069255047 = product of:
      0.020776514 = sum of:
        0.020776514 = weight(_text_:22 in 3696) [ClassicSimilarity], result of:
          0.020776514 = score(doc=3696,freq=2.0), product of:
            0.076713994 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.021906832 = queryNorm
            0.2708308 = fieldWeight in 3696, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.0546875 = fieldNorm(doc=3696)
      0.33333334 = coord(1/3)
  0.11111111 = coord(2/18)
    Abstract
    Provides examples to illustrate the growing use and acceptance of remote access to OPACs. Examines the differences between offering in-house public access and remote access to users and offers suggestions to help address some of the requirements of remote users. Discusses the shortcomings of the bibliographic record, what can be done to enhance the OPAC record, remote access to periodical indexes, access to the physical items represented by the bibliographic records, and the importance of establishing lines of communication with remote users
    Date
    8. 1.2007 17:22:42
  7. Machovec, G.S.: Administrative considerations in establishing remote dial-in access to an online catalog (1988) 0.00 
    5.6297285E-4 = product of:
  0.010133511 = sum of:
    0.010133511 = weight(_text_:in in 3101) [ClassicSimilarity], result of:
      0.010133511 = score(doc=3101,freq=4.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.34006363 = fieldWeight in 3101, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.125 = fieldNorm(doc=3101)
  0.055555556 = coord(1/18)
  8. Pospischil, R.: ¬A bypass for the local loop : Deutsche Telekom's strategy for fiber to the home (1995) 0.00 
    4.266052E-4 = product of:
  0.0076788934 = sum of:
    0.0076788934 = weight(_text_:in in 3774) [ClassicSimilarity], result of:
      0.0076788934 = score(doc=3774,freq=12.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.2576908 = fieldWeight in 3774, product of:
          3.4641016 = tf(freq=12.0), with freq of:
            12.0 = termFreq=12.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0546875 = fieldNorm(doc=3774)
  0.055555556 = coord(1/18)
    Abstract
    Technological and regulatory developments are opening the door for competition and new services in the local loop. The reunification of Germany created an opprotunity for Deutsche Telekom to install fibre in the loop on a large scale in eastern Germany. Deutsche Telekom's strategy consists of 4 steps: fibre in the loop is seen as a process innovation. New broadband services - product innovations - can be based on the process innovation. Only a sufficient number of installations will enable the industry to invest in new products. Besides the local networks equipped with fibre, there is an overlay network for the rapid delivery of fibre access for business customers. The experience gained in eastern Germany will be transferred to western Germany when tranforming its existing network structure
  9. Reddy, E.R.; Pradeep, C.: Internet and Z39.50 : a virtual union catalog (1999) 0.00 
    3.51858E-4 = product of:
  0.0063334443 = sum of:
    0.0063334443 = weight(_text_:in in 352) [ClassicSimilarity], result of:
      0.0063334443 = score(doc=352,freq=4.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.21253976 = fieldWeight in 352, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.078125 = fieldNorm(doc=352)
  0.055555556 = coord(1/18)
    Source
    CALIBER 99: Academic libraries in the Internet: Proceedings of the 6th National Convention for Automation of Libraries in Education and Research, Nagpur, India, 18.-20.2.1999. Ed. by P.S.G. Kumar and C.P. Vahishth
  10. Maio, A.; Littlefield, W.: Issues in mounting a commercial database on an online catalog (1992) 0.00 
    3.4832166E-4 = product of:
  0.0062697898 = sum of:
    0.0062697898 = weight(_text_:in in 4216) [ClassicSimilarity], result of:
      0.0062697898 = score(doc=4216,freq=8.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.21040362 = fieldWeight in 4216, product of:
          2.828427 = tf(freq=8.0), with freq of:
            8.0 = termFreq=8.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0546875 = fieldNorm(doc=4216)
  0.055555556 = coord(1/18)
    Abstract
    Hartford University mounted a DRA Atlas Integrated library system in 1991, using a DECnet/Ethernet network and a VAX 6310 mainframe computer. As VAX VT320 terminals were available in many campus buildings, the library's catalogue could be searched from many locations and could be dialed up by remote users. Commercial databases in MARC format could be mounted on the system and searched with the same commands that users employed for the OPAC. Explains the use of Periodical Abstracts from UMI on the online catalogue. Discusses searching strategies and compares the Periodical Abstracts Ondisc CD-ROM with the tape loaded product
  11. Blackmann, C.; Cave, M.; David, P.A.: competition, regulation, trade and standards : ¬The new international telecommunications environment (1996) 0.00 
    3.4832166E-4 = product of:
  0.0062697898 = sum of:
    0.0062697898 = weight(_text_:in in 8023) [ClassicSimilarity], result of:
      0.0062697898 = score(doc=8023,freq=2.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.21040362 = fieldWeight in 8023, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.109375 = fieldNorm(doc=8023)
  0.055555556 = coord(1/18)
    Abstract
    Einführender Artikel in das Themenheft
  12. Bell, S.J.: Providing remote access to CD-ROMs : some practical advice (1993) 0.00 
    3.4474907E-4 = product of:
  0.0062054833 = sum of:
    0.0062054833 = weight(_text_:in in 3748) [ClassicSimilarity], result of:
      0.0062054833 = score(doc=3748,freq=6.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.2082456 = fieldWeight in 3748, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0625 = fieldNorm(doc=3748)
  0.055555556 = coord(1/18)
    Abstract
    Discusses the factors influencing remote access to CD-ROMs: how many CD-ROM workstations are located at the place of work (single or multiple workstations); whether a PC or a CD-ROM LAN is in operation; what level of security is needed in the organisation; how many remote users need to be accomodated; and the level of software sophistication present in the staff of the organisation
  13. Fitzwater, D.; Fragkin, B.; Birttain, W.: Remote use of CD-ROM (1991) 0.00 
    3.4474907E-4 = product of:
  0.0062054833 = sum of:
    0.0062054833 = weight(_text_:in in 4831) [ClassicSimilarity], result of:
      0.0062054833 = score(doc=4831,freq=6.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.2082456 = fieldWeight in 4831, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0625 = fieldNorm(doc=4831)
  0.055555556 = coord(1/18)
    Abstract
    CD-ROM databases are finding a permanent niche in libraries and librarians are trained both to use each new product and to keep abreast of changes in them. From the library user point of view it is possible to dial into or remotely access CD-ROM databases. Discusses the use of the communications software pcAnywhere, examines the benefits to users and libraries of remote access, and lists other areas which might be of interest to learning resource centres in regard to CD-ROM services
  14. Ciardhuain, S.O.: Developments in networked bibliographic catalogues (1994) 0.00 
    3.4474907E-4 = product of:
  0.0062054833 = sum of:
    0.0062054833 = weight(_text_:in in 1589) [ClassicSimilarity], result of:
      0.0062054833 = score(doc=1589,freq=6.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.2082456 = fieldWeight in 1589, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0625 = fieldNorm(doc=1589)
  0.055555556 = coord(1/18)
    Abstract
    Computer and communications technology is having a profound impact on libraries and the way in which they serve their users. Discusses online catalogues in libraries, the development of the Internet and OSI, and the development of search and retrieve (SR) protocols to allow standardized access to library catalogues across communications networks. Considers the deployment of SR protocols, problems with interoperability of clients and servers, interlibrary loan possibilities of SR protocols, and the feasibility of electronic document delivery
  15. Boss, R.W.: Client/server technology for libraries with a survey of vendor offerings (1994) 0.00 
    3.4474907E-4 = product of:
  0.0062054833 = sum of:
    0.0062054833 = weight(_text_:in in 2604) [ClassicSimilarity], result of:
      0.0062054833 = score(doc=2604,freq=6.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.2082456 = fieldWeight in 2604, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0625 = fieldNorm(doc=2604)
  0.055555556 = coord(1/18)
    Abstract
    Defines client/server computer architecture and discusses it in the context of library automation. Addresses the following issues: is client/server needed?; the role of the Z39.50 standard; utilizing existing hardware and software; writing specifications; staff requirements; training; and ongoing support. Presents the responses of 30 library automation vendors in the USA to a questionnaire survey regarding present and future applications of client/server technology. Includes a bibliography of materials used in the preparation of the report
  16. Corey, J.F.: ¬A grant for Z39.50 (1994) 0.00 
    3.3380184E-4 = product of:
  0.006008433 = sum of:
    0.006008433 = weight(_text_:in in 7706) [ClassicSimilarity], result of:
      0.006008433 = score(doc=7706,freq=10.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.20163295 = fieldWeight in 7706, product of:
          3.1622777 = tf(freq=10.0), with freq of:
            10.0 = termFreq=10.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.046875 = fieldNorm(doc=7706)
  0.055555556 = coord(1/18)
    Abstract
    In Sept. 1990, the US Dept. of Education's Library Technology and Cooperation Grants Program awarded a three-year grant to the Florida Center for Library Automation (FCLA), an agency of the Florida State University System, to develop software adhering to the ANSI Z39.50 Information Retrieval protocol standard. The Z39.50 software was to operate over the OSI communications protocols and be integrated with FCLA's NOTIS system, which is shared by all 9 state universities in Florida. In order to test the correctness of its Z39.50 software, FCLA sought out other library software developers who would be willing to develop Z39.50 systems of their own. As part of this process, FCLA helped to found the Z39.50 Implementor's Group (ZIG), which has since gone on to improve the standard and promote Z39.50 implementations throughout much of the North American library systems marketplace. Early on in the project, it became apparent that TCP/IP would be a more heavily used communication vehicle for Z39.50 messages than OSI. FCLA expanded its design to include TCP/IP and, by the end of the grant in Sept. 1993, will have a working Z39.50 system that can communicate over both OSI and TCP/IP networks
  17. Meer, J. de: ¬The ISO reference model for open distributed processing (1995) 0.00 
    2.9856144E-4 = product of:
  0.0053741056 = sum of:
    0.0053741056 = weight(_text_:in in 3208) [ClassicSimilarity], result of:
      0.0053741056 = score(doc=3208,freq=2.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.18034597 = fieldWeight in 3208, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.09375 = fieldNorm(doc=3208)
  0.055555556 = coord(1/18)
    Abstract
    Details the elements of the ISO Reference Model for Open Distributed Processing. Explores the challenges facing in from multimedia and stream communication
  18. Poo, G.-S.; Chai, B.-P.: Modularity versus efficiency in OSI system implementations (1997) 0.00 
    2.8148643E-4 = product of:
  0.0050667557 = sum of:
    0.0050667557 = weight(_text_:in in 1895) [ClassicSimilarity], result of:
      0.0050667557 = score(doc=1895,freq=4.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.17003182 = fieldWeight in 1895, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0625 = fieldNorm(doc=1895)
  0.055555556 = coord(1/18)
    Abstract
    Examines a number of possible OSI system implementation strategies based on the various prevailing system facilities: processes, threads, kernel and front-end processors. Analyzes the pros and cons of the strategies showing their relative merits in implementation. The analysis leads to the recommendation of an enhanced subsystem architecture that holds the best compromise of the conflicting requirements of modularity and efficiency
  19. Lynch, C.A.: ¬The Z39.50 information retrieval standard : part I: a strategic view of its past, present and future (1997) 0.00 
    2.7927864E-4 = product of:
  0.005027015 = sum of:
    0.005027015 = weight(_text_:in in 1262) [ClassicSimilarity], result of:
      0.005027015 = score(doc=1262,freq=28.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.1686982 = fieldWeight in 1262, product of:
          5.2915025 = tf(freq=28.0), with freq of:
            28.0 = termFreq=28.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0234375 = fieldNorm(doc=1262)
  0.055555556 = coord(1/18)
    Abstract
    The Z39.50 standard for information retrieval is important from a number of perspectives. While still not widely known within the computer networking community, it is a mature standard that represents the culmination of two decades of thinking and debate about how information retrieval functions can be modeled, standardized, and implemented in a distributed systems environment. And - importantly -- it has been tested through substantial deployment experience. Z39.50 is one of the few examples we have to date of a protocol that actually goes beyond codifying mechanism and moves into the area of standardizing shared semantic knowledge. The extent to which this should be a goal of the protocol has been an ongoing source of controversy and tension within the developer community, and differing views on this issue can be seen both in the standard itself and the way that it is used in practice. Given the growing emphasis on issues such as "semantic interoperability" as part of the research agenda for digital libraries (see Clifford A. Lynch and Hector Garcia-Molina. Interoperability, Scaling, and the Digital Libraries Research Agenda, Report on the May 18-19, 1995 IITA Libraries Workshop, <http://www- diglib.stanford.edu/diglib/pub/reports/iita-dlw/main.html>), the insights gained by the Z39.50 community into the complex interactions among various definitions of semantics and interoperability are particularly relevant. The development process for the Z39.50 standard is also of interest in its own right. Its history, dating back to the 1970s, spans a period that saw the eclipse of formal standards-making agencies by groups such as the Internet Engineering Task Force (IETF) and informal standards development consortia. Moreover, in order to achieve meaningful implementation, Z39.50 had to move beyond its origins in the OSI debacle of the 1980s. Z39.50 has also been, to some extent, a victim of its own success -- or at least promise. Recent versions of the standard are highly extensible, and the consensus process of standards development has made it hospitable to an ever-growing set of new communities and requirements. As this process of extension has proceeded, it has become ever less clear what the appropriate scope and boundaries of the protocol should be, and what expectations one should have of practical interoperability among implementations of the standard. Z39.50 thus offers an excellent case study of the problems involved in managing the evolution of a standard over time. It may well offer useful lessons for the future of other standards such as HTTP and HTML, which seem to be facing some of the same issues.
    This paper, which will appear in two parts, starting with this issue of D-Lib, looks at several strategic issues surrounding Z39.50. After a relatively brief overview of the function and history of the protocol, I will examine some of the competing visions of the protocol's role, with emphasis on issues of interoperability and the incorporation of semantics. The second installment of the paper will look at questions related to the management of the standard and the standards development process, with emphasis on the scope of the protocol and how that relates back again to interoperability questions. The paper concludes with a discussion of the adoption and deployment of the standard, its relationship to other standards, and some speculations on future directions for the protocol. This paper is not intended to be a tutorial on the details of how current or past versions of Z39.50 work. These technical details are covered not only in the standard itself (which can admittedly be rather difficult reading) but also in an array of tutorial and review papers (see <http://lcweb.loc.gov/z3950/agency> for bibliographies and pointers to on-line information on Z39.50). Instead, the paper's focus is on how and why Z39.50 developed the way it did, and the conceptual debates that have influenced its evolution and use. While a detailed technical knowledge of the operation of Z39.50 is certainly helpful, it should not be necessary in order to follow most of the material here. Some disclaimers are in order. I have been actively involved in the development of Z39.50 since the early 1980s and have been a participant -- and on occasion, even an instigator -- of some of the activities described here. This paper is an attempt to make a critical assessment of the current state of Z39.50 and a review of its development with the full benefit of hindsight. It recounts a number of debates that occurred within the developer community over the past years. In many of these, I advocated specific positions or approaches, sometimes successfully and sometimes unsuccessfully. What is presented here is one person's perspective - mine --, which is sometimes at odds with the current consensus with the developer community; I've tried to represent opposing views fairly, and to differentiate my opinions from fact or consensus. However, others will undoubtedly disagree with many of the comments here.
  20. Needleman, M.: Z39.50: a review, analysis and some thoughts on the future (2000) 0.00 
    2.781682E-4 = product of:
  0.0050070276 = sum of:
    0.0050070276 = weight(_text_:in in 4898) [ClassicSimilarity], result of:
      0.0050070276 = score(doc=4898,freq=10.0), product of:
        0.029798867 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.021906832 = queryNorm
        0.16802745 = fieldWeight in 4898, product of:
          3.1622777 = tf(freq=10.0), with freq of:
            10.0 = termFreq=10.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0390625 = fieldNorm(doc=4898)
  0.055555556 = coord(1/18)
    Abstract
    This article will examine the Z39.50 Information Retrieval protocol. It will look at some of the history of the protocol, its operation, and some of the major projects that have made use of it. There has been enough written (perhaps too much) about Z39.50 in the last several years so it is not intended to be a tutorial or detailed description of the protocol. The material that will be presented will try and put some context around the discussion. For those readers who are interested in delving into Z39.50 in a more technical manner, references to much of the material that has been written about it over the years will be provided at the end. Finally, the article will conclude with some thoughts on how technology and technological infrastructure have changed in the years since Z39.50 was initially developed and deployed, and where the protocol has so far lived up to its goals, and where it has perhaps failed to meet some of the high expectations that at least some people involved in the Z39.50 community held for it. The article will conclude with some of the author's speculations (and they are really no more than that) of what the future role of Z39.50 is likely to be.

Authors

Years

Themes