[Allegro] Allegro Nachrichtensammlung, Band 124, Eintrag 2

Carsten Elsner el at biblio.tu-bs.de
Di Apr 7 10:55:42 CEST 2015



Am 07.04.2015 um 10:34 schrieb allegro-request at biblio.tu-bs.de:
> Um E-Mails an die Liste Allegro zu schicken, nutzen Sie bitte die
> Adresse
>
> 	allegro at biblio.tu-bs.de
>
> Um sich via Web von der Liste zu entfernen oder draufzusetzen:
>
> 	http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro
>
> oder, via E-Mail, schicken Sie eine E-Mail mit dem Wort 'help' in
> Subject/Betreff oder im Text an
>
> 	allegro-request at biblio.tu-bs.de
>
> Sie koennen den Listenverwalter dieser Liste unter der Adresse
>
> 	allegro-owner at biblio.tu-bs.de
>
> erreichen
>
> Wenn Sie antworten, bitte editieren Sie die Subject/Betreff auf einen
> sinnvollen Inhalt der spezifischer ist als "Re: Contents of Allegro
> digest..."
>
>
> Meldungen des Tages:
>
>     1. Re: RDA: Inhaltstyp und Datenträgertyp (Bernhard Eversberg)
>     2. Re: RDA: Inhaltstyp und Datenträgertyp (Thomas Berger)
>     3. Re: RDA: Inhaltstyp und Datenträgertyp (Bernhard Eversberg)
>     4. Schnelle Suche in alcarta (Osterhus)
>     5. Re: Schnelle Suche in alcarta (Bernhard Eversberg)
>     6. Re: Schnelle Suche in alcarta (Thomas Berger)
>     7. Windows 7 (Panski, Regine)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 01 Apr 2015 11:17:53 +0200
> From: Bernhard Eversberg <ev at biblio.tu-bs.de>
> To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>
> Subject: Re: [Allegro] RDA: Inhaltstyp und Datenträgertyp
> Message-ID: <551BB7C1.6030700 at biblio.tu-bs.de>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Am 01.04.2015 um 10:47 schrieb Anando Eger:
>> Ich bin dringend dafür etwas festzulegen, was NICHT mit dem
>> offiziellen $A-Schema kollidiert:
>>
> Wie gesagt, festgelegt ist noch nichts. Mir ging's ja gerade darum,
> Vorschläge zu hören, die konsensfähig sind. Deshalb hatte ich
> einen Vorschlag gemacht, der es sicher nicht ist.
>
> Wobei ich, wie vorhin angedeutet, nicht überzeugt bin, daß eine
> Mehrheit überhaupt diese Neuerungen haben will und sich was
> davon verspricht. In eine Arbeitsbeschaffungsmaßnahme sollte
> die RDA-Hinwendung sicher nicht ausarten.
>
> B.E.
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 01 Apr 2015 11:38:00 +0200
> From: Thomas Berger <ThB at Gymel.com>
> To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>
> Subject: Re: [Allegro] RDA: Inhaltstyp und Datenträgertyp
> Message-ID: <551BBC78.5040805 at Gymel.com>
> Content-Type: text/plain; charset=utf-8
>
> Lieber Herr Eversberg, liebe Liste,
>
>>>>> wohingegen der Medientyp zur Expression gehoert...
>>>>>
>>>> Sicher, aber es werden keine Expressions-Datensätze gemacht werden.
>>> Es werden auch keine Werk-Saetze gemacht werden, bzw. konkret
>>> keine bibliographischen (Mehr GND-Saetze fuer Werke sind allerdings
>>> zu erwarten).
>> Die bisher existierenden GND-Werksätze entstammen fast alle aus dem
>> Musikbereich. Die "bevorzugten" Titel folgen den strikten Formalien
>> von RAK-Musik. Ob man mit den GND-Daten einen RDA-konformen
>> Werksatz hinkriegen kann, so man das will, überblicke ich noch nicht,
> Man koennte. Es ist aber nicht geplant, die Werk bzw. Person-Werk-
> Saetze aus der GND (also MARC Authorities) herauszunehmen und
> in etwas bibliographisches umzuwandeln. Im Gegenteil: In VIAF
> kann man besichtigen, dass die LoC seit laengerer Zeit auch
> Expression-Saetze als Normdatensaetze produziert.
>
> Datentechnische /Trennung/ der Katalogisate in die verschiedenen
> Entitaeten Werk-Expression-Manifestation ist nach RDA zwar
> moeglich, wird m.W. aber derzeit von keiner der involvierten
> Parteien angestrebt, es ist eher als eine Option zu verstehen,
> die zukuenftige Datenformate nutzen koennten (derzeit sind die
> aber eher RDF-basiert, d.h. "records" gibt es eher gar nicht...)
>
>
>
>> ein kompatibler Inhaltstyp existiert da jedenfalls nicht.
>> BSZ hat übrigens gerade ein umfassendes GND-Handbuch aufgelegt:
>>    http://verbund-swop.bsz-bw.de/volltexte/2013/340/pdf/kathb_gnd.pdf
> Schoen. Dann liegen ja alle genau im Plan (zum 31.3. die gemeinsamen
> Schulungsunterlagen der Verbuende fertigzustellen)
>
>
>>>> Und ein konkreter Inhalt sähe so aus, ein wenig vereinfacht:
>>>>
>>>> #77i $a aufgeführte Musik $b prm $2 rdacontent
>>>> #77m $a audio $b s $2 rdamedia
>>>> #77d $a Audiodisk $b sd $2 rdacarrier
>>> $2 ist wichtig, zumindest wenn nicht "rdacontent" drin steht
>>> (wir haben uns noch nicht ueber ein Globalfeld unterhalten,
>>> das festlegt, dass die Aufnahme als Ganzes unter RDA zustande
>>> gekommen ist - es wird ja oft genug darauf hingewiesen, dass
>>> es nicht ausreicht, nur die drei CMC-Sachverhalte auszufuellen)
>>>
>>> $a erwarte ich als typischen Inhalt von Nicht-D-A-CH-Daten (dann
>>> eher auf Englisch oder Suaheli), in D-A-CH wird es stets belegt
>>> sein, allerdings wohl meist "beim Export" aus den Codes $b
>>> abgeleitet.
>>>
>> Die Kernfrage ist doch, ob man die Daten der MARC-Felder 336, 337 und
>> 338, wenn sie aus verschiedenen Quellen stammen, dann überhaupt wird
>> logisch zusammenführen können. Die Begriffe und/oder die Semantik von
>> Codes können nach aller Erfahrung stark divergieren.
> /Wenn/ da dann aber $rdacontent steht, ist die Semantik festgezurrt
> und man hat "nur" noch Uebersetzungs- oder Code-umsetzungsprobleme
> oder solche die aus Vergroeberungen bzw. Verfeinerungen /kompatibler/
> Konzepte resultieren ;-)
>
> Aber es hat doch sowieso nie jemand die offizielle Begruendung ernst
> genommen, dass durch "Internationalisierung" der beruehmte "Datentausch"
> einfacher wird.
>
>
>> Hinzu kommt natürlich das Problem mit den Altdaten, die zum großen
>> Teil weniges enthalten, womit man die neuen Felder beschicken könnte.
>> Die von LC für MARC21 definierten Codes stammen alle aus ein paar
>> festen Bytes, vorwiegend aus dem Header und aus der 007, die es
>> schon länger gibt. Aber wir haben in MAB2 dafür nichts adäquates
>> und in Pica auch nicht.
>> Und was, frage ich, nützt einem dann der ganze Aufwand, wenn
>> die Daten nicht komplett damit ausgestattet sind und in nicht
>> konsistenter Weise?
> Nun, bekanntermassen ist es eben nicht moeglich, Altkatalogisate
> automatisch nach RDA umzusetzen. Man koennte sich sonst auch
> fragen, wozu ein neues Regelwerk gut sein soll, wenn es dann doch
> nur Daten produziert, die man auch durch Umsetzung von Alt-Daten
> aus Alt-Regelwerken erreichen kann.
>
> Die Argumentation ist ansonsten nicht neu, aber dennoch haben
> alle fleissig ihre PI-Kataloge retrokonvertiert und in die
> Verbunddatenbanken eingespielt, auch wenn die dadurch nicht mehr
> "reine" RAK-Umgebungen waren.
>
> viele Gruesse
> Thomas Berger
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 01 Apr 2015 11:48:44 +0200
> From: Bernhard Eversberg <ev at biblio.tu-bs.de>
> To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>
> Subject: Re: [Allegro] RDA: Inhaltstyp und Datenträgertyp
> Message-ID: <551BBEFC.60303 at biblio.tu-bs.de>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Am 01.04.2015 um 11:38 schrieb Thomas Berger:
>> Die Argumentation ist ansonsten nicht neu, aber dennoch haben
>> alle fleissig ihre PI-Kataloge retrokonvertiert und in die
>> Verbunddatenbanken eingespielt, auch wenn die dadurch nicht mehr
>> "reine" RAK-Umgebungen waren.
>>
> Ja eben. Deshalb muß man doch auch überlegen, was man brauchen kann und
> wofür, und ob man sich's leisten kann. Dazu würde man gerne auch
> Meinungen von Praktikern hören.
>
> Jetzt also Klartext: Welche Felder sollen es sein, was soll's bringen,
> und was muß demnach da rein - aber was nicht?
>
> B.E.
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 1 Apr 2015 12:04:00 +0200
> From: Osterhus, Dr. Ulrich (LG-Lübeck)
> 	<Ulrich.Osterhus at LG-Luebeck.LandSH.de>
> To: <allegro at biblio.tu-bs.de>
> Subject: [Allegro] Schnelle Suche in alcarta
> Message-ID:
> 	<2BD7F2953C40B643B1D176A86EF51ADDA4EFC1 at lg-hl-srv1.jnv.justizsh.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hallo und guten Tag,
>
>   
>
> ein Mitarbeiter im Hause hat alcarta aufgerufen und in der Schnellen Suche NJW eingegeben. In der Ergebnismenge sind alle Treffer der NJW-Schriftenreihe aufgeführt nur nicht die Zeitschrift NJW. Die Zeitschriften sind hier mit #8n aufgenommen und werden im Register 10 über njw oder _njw abgegriffen. In alcarta (hier access=0) ist dieses Register nicht benutzbar. Mit Alt+f gibt es auch kein Ergebnis.
>
>   
>
> Natürlich kann man mit Alt+5 das Register aufrufen und dann neue ju? oder neue juristische wochenschrift aufrufen. Damit kann ich aber nicht punkten. Der Praktiker will hier keine Romane eintippen. Gibt es eine praktikable Lösung für das Problem.
>
>   
>
> Mit freundlichen Grüßen
>
> Ulrich Osterhus
>
>   
>
>   
>
> Dr. Ulrich Osterhus
>
> Bibliothek des Landgerichts | Am Burgfeld 7 | 23568 Lübeck
>
> Telefon 0451 371-1788 | Telefax 0451 371-1519
>
> E-Mail Ulrich.Osterhus at lg-luebeck.landsh.de <mailto:Ulrich.Osterhus at lg-luebeck.landsh.de>
>
>   
>
> -------------- nächster Teil --------------
> Ein Dateianhang mit HTML-Daten wurde abgetrennt...
> URL: <http://sunny5.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20150401/15f0293c/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 01 Apr 2015 12:33:25 +0200
> From: Bernhard Eversberg <ev at biblio.tu-bs.de>
> To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>
> Subject: Re: [Allegro] Schnelle Suche in alcarta
> Message-ID: <551BC975.9050205 at biblio.tu-bs.de>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Am 01.04.2015 um 12:04 schrieb Osterhus, Dr. Ulrich (LG-Lübeck):
>> ein Mitarbeiter im Hause hat alcarta aufgerufen und in der Schnellen
>> Suche NJW eingegeben. In der Ergebnismenge sind alle Treffer der
>> NJW-Schriftenreihe aufgeführt nur nicht die Zeitschrift NJW. Die
>> Zeitschriften sind hier mit #8n aufgenommen und werden im Register 10
>> über njw oder _njw abgegriffen. In alcarta (hier access=0) ist dieses
>> Register nicht benutzbar. Mit Alt+f gibt es auch kein Ergebnis.
>>
> Die Schnelle Suche findet nur statt im Register 1 der Indexdatei .aex.
>
> Wenn Sie den NJW-Satz nehmen und dann F7, sehen Sie dann den Eintrag
>
> ~e1njw
>
> Wenn ja, dann weiß ich nicht weiter.
>
> Wenn nicht, dann in die Indexparameter diese Zeile rein:
> (irgendwo zwischen die anderen ak-Zeilen)
>
> ak=8n." "+z
>
> Dann mit F7 kontrollieren (nach a99-Neustart) und, wenn der
> besagte Schlüssel dann zu sehen ist,  "Index erneuern"
>
> B.E.
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 01 Apr 2015 12:51:11 +0200
> From: Thomas Berger <ThB at Gymel.com>
> To: Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>
> Subject: Re: [Allegro] Schnelle Suche in alcarta
> Message-ID: <551BCD9F.2010201 at Gymel.com>
> Content-Type: text/plain; charset=utf-8
>
> Am 01.04.2015 um 12:33 schrieb Bernhard Eversberg:
>> Am 01.04.2015 um 12:04 schrieb Osterhus, Dr. Ulrich (LG-Lübeck):
>>> ein Mitarbeiter im Hause hat alcarta aufgerufen und in der Schnellen
>>> Suche NJW eingegeben. In der Ergebnismenge sind alle Treffer der
>>> NJW-Schriftenreihe aufgeführt nur nicht die Zeitschrift NJW. Die
>>> Zeitschriften sind hier mit #8n aufgenommen und werden im Register 10
>>> über njw oder _njw abgegriffen. In alcarta (hier access=0) ist dieses
>>> Register nicht benutzbar. Mit Alt+f gibt es auch kein Ergebnis.
>>>
>> Die Schnelle Suche findet nur statt im Register 1 der Indexdatei .aex.
>>
>> Wenn Sie den NJW-Satz nehmen und dann F7, sehen Sie dann den Eintrag
>>
>> ~e1njw
>>
>> Wenn ja, dann weiß ich nicht weiter.
>>
>> Wenn nicht, dann in die Indexparameter diese Zeile rein:
>> (irgendwo zwischen die anderen ak-Zeilen)
>>
>> ak=8n." "+z
>>
>> Dann mit F7 kontrollieren (nach a99-Neustart) und, wenn der
>> besagte Schlüssel dann zu sehen ist,  "Index erneuern"
> Tatsache ist (vgl. "Bibliotheksdienst" in der Demo-Datenbank), dass
> #8n ff nicht ins erweiterte Stichwortregister geraten.
>
> Die Frage ist allerdings allgemein, warum Anwender (nicht nur Herr Osterhus,
> sondern m.E. eigentlich alle) beharrlich Nicht-Titelaufnahmen ("#8n-Saetze")
> fuer Zeitschriften herstellen und dann darauf bestehen, dass die sich so
> verhalten wie Titelaufnahmen. Allerdings ist es so, dass diese "#8n-Saetze"
> oft stark mit normalen bibliographischen Feldern angereichert werden und daher
> alles moegliche von ihnen in allen moeglichen Registern auftaucht - nur eben
> in Bezug auf die eigentlichen Titel sind sie unsichtbar.
>
> Dahinter mag stecken, dass das urspruenglich (so etwa vor 1990?) eher
> fuer Reihen als fuer Zeitschriften gedacht gewesen ist und/oder
> vermieden werden sollte, dass in den Registern etwas anderes ausser
> "Stuecken" bzw. "Baenden" auffindbar sein sollte, man wollte sich
> wohl Diskussionen darueber ersparen, warum der Benutzer nicht "den
> Bibliotheksdienst" ausleihen oder anfordern koennen soll...
>
> Als Alternative gab es aber stets das Anlegen von "normalen" Zeitschriften-
> Titelaufnahmen, zu Zeiten, wo man autopsieren musste, war das allerdings
> praktisch aussichtslos, das mag ein weiterer Grund fuer die Nicht-
> Titelaufnahmen sein. Seit 2001 ist die ZDB aber vorzueglich online, so
> dass man die dortigen Saetze konsultieren kann, ausserdem funktioniert
> auch der Datenimport per dnb.flx fuer ZDB-Saetze ueberraschend gut
> (das DNB-System ist ja die technische Plattform fuer die ZDB, insofern
> sind alle(?) ZDB-Titel auch ueber das DNB-Portal recherchierbar - sehr
> zur Irritation der DNB-Benutzer. Einziger Wermutstropfen ist, dass
> das DNB-Portal die ZDB-Nummer nicht zeigt, die muss ueber den ZDB-
> OPAC im Zweifel nachrecherchiert werden...)
>
> viele Gruesse
> Thomas Berger
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 7 Apr 2015 10:34:56 +0200
> From: "Panski, Regine" <Regine.Panski at kg.berlin.de>
> To: <allegro at biblio.tu-bs.de>
> Subject: [Allegro] Windows 7
> Message-ID:
> 	<624A983AA3370E42A67C2800E55645ED08645FAA at kgnt1.kg.verwalt-berlin.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Guten Tag,
>
> ich habe hier jetzt einen Windows-7-Rechner. Ich möchte in einer Datei mit x.exe suchen. Ich gebe ein: f  ---
>
> es wird aber /// geschrieben und dann natürlich nicht das Richtige gefunden. Ich habe folgende Zeilen in config.nt ergänzt:
>
> dos=high, umb
>
> device=%SystemRoot%\system32\himem.sys
>
> device=%SystemRoot%\system32\ansi.sys
>
> Shell=%SystemRoot%\system32\command.com C:\ /E:2048 /P
>
> files=90
>
>   
>
> Hat aber auch nicht geholfen.
>
> Weiß jemand Rat?
>
>   
>
> Mit freundlichen Grüßen
>
>   

Das sieht mir ganz nach einem englischen Tastaturlayout aus. Was steht 
denn unten rechts als Eingabesprache? EN? Dann einfach mit ALT+SHIFT 
wieder auf DE umschalten.

Gruss,

C. Elsner

> Regine Panski
>
>   
>
> -------------- nächster Teil --------------
> Ein Dateianhang mit HTML-Daten wurde abgetrennt...
> URL: <http://sunny5.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20150407/8a92f36e/attachment.html>
>
> ------------------------------
>
> Subject: Fusszeile der Nachrichtensammlung
>
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro
>
> ------------------------------
>
> Ende Allegro Nachrichtensammlung, Band 124, Eintrag 2
> *****************************************************




Mehr Informationen über die Mailingliste Allegro