The configuration file uses ZIPPlug and MARCPlug, apart from the standard four. There are three classifiers, based on Title, Creator, and Subject metadata. All are AZCompactList classifiers, and all specify a mingroup of 1. This forces them to create a bookshelf icon even if there is only one item on the shelf (like this). The reason is aesthetic: the list has a uniform appearance: all items look the same, including one-book entries. (Of course, if you don\'t like this style, just leave out the mingroup argument.) A second argument for the Title and Creator classifiers removes suffixes from the metadata string (Title and Creator respectively). This is specified as a PERL regular expression, and trims characters (such as trailing punctuation) from the strings for display. The three format statements are similar: in particular, they each put out the number of leaf documents on the right-hand side of the display, as you can see here.\n
The MARC plugin uses a special file to map MARC field numbers to Greenstone-style metadata. This file resides in the gsdl/etc directory, and is called marctodc.txt. It lists the correspondences between MARC field numbers and Greenstone metadata. Any MARC fields that are not listed simply do not appear as metadata, though they are still present in the Greenstone document. Each line in the file has the format
<MARC field number> --> GreenstoneMetadataNameLines in the file that begin with \"\#\" are comments (however, comments have been stripped out of the listing below).\n
The standard version of this file is loosely based on the MARC to Dublin Core mapping found at http://lcweb.loc.gov/marc/dccross.html (which assumes USMARC/MARC21), and contains these lines:\n
gsdl/etc/marctodc.txt
\n
720 --> Creator
\n
100 --> Creator
\n
110 --> Creator
\n
111 --> Creator
\n
520 --> Description
\n
856 --> URL
\n
260 --> Publisher
\n
787 --> Relation
\n
540 --> Rights
\n
024 --> MarcIdentifier
\n
786 --> MarcSource
\n
546 --> MarcLanguage
\n
650 --> Subject
\n
653 --> Subject
\n
245 --> Title
\n
655 --> Type\n
Several different MARC fields are mapped on to Dublin Core Creator. Field 720 is \"Uncontrolled name,\" 100 is \"Personal name,\" 110 is \"Corporate name,\" 111 is \"Meeting name.\" Actual MARC records normally define only one of these fields, and anyway Greenstone allows multi-valued metadata.\n
MARC field 520 (\"Summary, note\") is mapped to Dublin Core Description; field 856 (\"Electronic location\") is mapped to URL; field 787 (\"Nonspecific relationship note\") to Relation; field 540 (\"Reproduction note\") to Rights; field 245 (\"Title statement\") to Title; field 655 (\"Index term - genre/form\") to Type. Both fields 650 (\"Subject: topical term\") and 653 (\"Index term: uncontrolled\") are mapped to Subject.\n
MARC field 024 (\"Identifier\") is not mapped to Greenstone metadata, because Greenstone uses its own Identifier metadata; instead it is mapped to a different Greenstone metadata element called MarcIdentifier. Likewise field 786 (\"Data source entry\") is not mapped to Source, because Greenstone has Source metadata, but to a new metadata field called MarcSource instead; and field 546 (\"Language\") is mapped to MarcLanguage.\n
Some MARC fields with Dublin Core counterparts are simply ignored, e.g. 620 (Contributor) and 500 (Coverage). MARC field 260 is called \"Publication, etc\") and is mapped in its entirety to Publisher. In fact, field 260c (a subfield) is supposed to be publication date, but is not mapped as such.\n
Of course, different mappings can be defined by altering the above file-which allows the MARC plugin to support other variants of the MARC format. The plugin does not recognize individual MARC subfields: it simply concatenates them together. However, enhancing it to deal appropriately with subfields would not be a difficult job: it would involve altering a couple of pages of PERL code in the MARC plugin. " # -- French text ---------------- collectionmeta collectionextra [l=fr] "Cette collection, which contains _about:numdocs_ MARC entries, is based on the MARC records of working papers published by Computer Science Department at the University of Waikato. Voici un document échantillon dans la collection.
Le fichier de configuration utilise ZipPlug et MarcPlug à coté des trois qui sont utilisés en standard. Il y a trois classificateurs basés sur les méta-données Title, Creator et Subject. Tous sont dans des classificateurs AZCompact et tous précisent un mingroup de 1. Ceci les oblige à créer une icône de rayon de livres, même s\'il n\'y a qu\'un seul élément dans le rayon (comme celui-ci). La raison est d\'ordre esthétique : la liste a une apparence uniforme; tous les éléments se ressemblent, y compris les entrées ne contenant qu\'un seul livre. (Evidement, si vous n\'aimez pas ce style, abandonnez simplement l\'argument mingroup). Un deuxième argument pour les classificateurs Title et Creator enlèvent les suffixes de la chaîne de méta-données (Title et Creator respectivement). Ceci est spécifié comme une expression régulière de PERL et ajuste pour l\'affichage des caractères (comme une ponctuation finale). Les trois déclarations de mise en forme sont identiques : en particulier, elles sortent le nombre de documents en bout de l\'arborescence dans le côté droit de l\'affichage, comme on le voit ici.
Le module Marc utilise un fichier spécial pour la mise en correspondance des numéros de champ MARC avec les méta-donnée de type Greenstone. Ce fichier se trouve dans le répertoire gsdl/etc, et est appelé marctodc.txt. Il liste les correspondences entre les numéros de champ MARC et les méta-données Greenstone. Tous les champs MARC qui ne sont pas listés ne vont pas apparaître comme méta-données, bien qu\'ils spient toujours présents dans le document Greenstone. Chaque ligne dans le fichier à le format:
<numéro de champ MARC> --> NonMetadonnéeGreenstoneLes lignes dans le fichier qui commence par \"\#\" sont des commentaires (cependant, les commentaires ont été enlevées du listing ci-dessous).
La version standard de ce fichier est approximativement basée sur la mise en correspondance MARC - Dublin Core trouvé à http://lcweb.loc.gov/marc/dccross.html (qui suppose USMARC/MARC21), et contient ces lignes :
gsdl/etc/marctodc.txt
720 --> Creator
100 --> Creator
110 --> Creator
111 --> Creator
520 --> Description
856 --> URL
260 --> Publisher
787 --> Relation
540 --> Rights
024 --> MarcIdentifier
786 --> MarcSource
546 --> MarcLanguage
650 --> Subject
653 --> Subject
245 --> Title
655 --> Type
Plusieurs champs MARC mis en correspodance avec Creator de Dublin Core. Le champ 720 est \"Uncontrolled name,\" 100 est \"Personal Name,\" 110 est \"Corporate Name,\" 111 est \"Meeting Name.\" Les enregistrements MARC actuels définissent normallement seulement un de ces champs, et de toutes les façons Greenstone permet des méta-données à valeurs multiples.
Le champ MARC520 (\"Summary note\") est mis en correspodance avec Description de Dublin Core; le champ 856 (\"Electronic location\") mis en correspondance avec URL; champ 787 (\"Nonspecific relationship note\") avec Relation; le champ 540 (\"Reproduction note\") avec Rights; le champ 245 (\"Title statement\") avec Title ; le champ 655 (\"Index term-genre/form\") avec Type. Les deux champs 650 (\"Subject: topical term\") et 653 (\"Index term: incontrolled\") sont mis en correspondance avec Subject.
Le champ MARC 024 (\"Identifier\") n\'est pas mis en correspondance avec avec des méta-données Greenstone parce que Greenstone utilise sa propre méta-donnée Identifier; à la place il est mis en correspondance avec autre méta-donnée Greenstone appelée MarcIdentifier. De même, le champ 786 (\"Data source entry\") n\'est pas mis en correspodance avec Source, parce que Greenstone a une méta-donnée Source, mais avec un nouveau champ de méta-donnée applelé MarcSource; et le champ 546 (\"Language\") est mis en correspondance avec MarcLanguage.
Quelques champs MARC avec des correspondances Dublin Core sont tout simplement ignorés, p. ex: 620 (Contributor) et 500 (Coverage). Le champ MARC 260 est appelé \"Publication, etc\" et est mis en correspondance dans sa globalité avec Publisher. En fait, le champ 260c (un \"sous-champ\") est supposé être une date de publication mais n\'est pas mis en correspondance comme tel.
Naturellement, plusieurs mises en correspondances peuvent être définies en modifiant les fichiers ci-dessus, ce qui permet au plugin MARC de supporter les autres variantes du format MARC. Le plugin ne reconnaît pas les sous-champs MARC: Il les concatène tout simplement. Cependant, l\'améliorer pour traiter convenablement avec les sous-champs ne devrait pas être un travail difficile: cela impliquerait la modification de quelques pages de code PERL dans le plugin Marc. " # -- Spanish text ---------------- collectionmeta collectionextra [l=es] "Esta colección, which contains _about:numdocs_ MARC entries, is based on the MARC records of working papers published by Computer Science Department at the University of Waikato. He aquí un documento muestra de la colección.
El archivo de configuración utiliza ZIPPlug y MARCPlug además de los tres plugins estándar. Existen tres clasificadores basados en los metadatos Título, Creador y Asunto. Todos son clasificadores AZCompactList y todos especifican un mingroup de 1. Esto los fuerza a crear un icono de estante inclusive si sólo hay un ítem en el estante (de esta manera). La razón es puramente estética: La lista tiene una apariencia uniforme en la que todos los ítems se ven iguales, incluyendo entradas de un solo libro. (Por supuesto, si no le gusta este estilo, sólo tiene que dejar fuera el argumento mingroup). Un segundo argumento para los clasificadores de Título y Creador quita los sufijos de la cadena del metadato (Título y Creador, respectivamente). Esto se especifica como una expresión regular PERL y ordena los caracteres (como la puntuación que se encuentra al final) a partir de las cadenas para su presentación en pantalla. Los tres enunciados de formato son similares: en particular, cada uno de ellos muestra el número de documentos a la derecha de la pantalla, tal como se puede ver aquí.
El plugin de MARC utiliza un archivo especial para mapear y convertir los números de campo MARC a metadatos estilo Greenstone. Este archivo reside en el directorio gsdl/etc y se llama marctodc.txt. Incluye una lista de las correspondencias entre los números de campo MARC y los metadatos Greenstone. Cualquier campo MARC que no esté incluido en la lista simplemente no aparece como metadato, aunque siga estando presente en el documento Greenstone. Cada línea del archivo tiene el siguiente formato:
<MARC field number> --> GreenstoneMetadataName
Las líneas en el archivo que empiezan con \"\#\" son comentarios. (Los comentarios no han sido incluidos en la lista que aparece más abajo).
La versión estándar de este archivo se basa libremente en el mapeo de MARC a Dublin Core que se encuentra en http://lcweb.loc.gov/marc/dccross.html (el cual asume USMARC/MARC21) y contiene las siguientes líneas:
gsdl/etc/marctodc.txt
\n
720 --> Creator
\n
100 --> Creator
\n
110 --> Creator
\n
111 --> Creator
\n
520 --> Description
\n
856 --> URL
\n
260 --> Publisher
\n
787 --> Relation
\n
540 --> Rights
\n
024 --> MarcIdentifier
\n
786 --> MarcSource
\n
546 --> MarcLanguage
\n
650 --> Subject
\n
653 --> Subject
\n
245 --> Title
\n
655 --> Type\n
Varios campos MARC diferentes han sido mapeados hacia el metadato Creator (Creador) de Dublin Core. El campo 720 es \"nombre no controlado\", el 100 es \"nombre de la persona\", el 110 es \"nombre de la compañía\" y el 111 es \"nombre de la reunión\". Por lo general los registros MARC únicamente definen uno de estos campos y de cualquier manera Greenstone permite metadatos con múltiples valores.
El campo 520 de MARC (\"Resumen, nota\") ha sido mapeado hacia el metadato Description (Descripción) de Dublin Core; el campo 856 (\"Dirección electrónica\") ha sido mapeado hacia URL; el campo 787 (\"Nota de relación no específica\") hacia Relation (Relación); el campo 540 (\"nota sobre la reproducción\") hacia Rights (Derechos de autor); el campo 245 (\"enunciado del título\") hacia Title (Título); el campo 655 (\"término del índice - género/forma\") hacia Type (Tipo). Los campos 650 (\"Asunto: tópico\") y 653 (\"término del índice: no controlado\") han sido mapeados hacia Subject (Asunto).
El campo 024 de MARC (\"Identificador\") no ha sido mapeado hacia un metadato de Greenstone, ya que Greenstone utiliza su propio metadato Identificador. En vez de eso ha sido mapeado hacia un elemento de metadato Greenstone diferente llamado MarcIdentifier. Del mismo modo el campo 786 (\"Entrada de la fuente del dato\") no ha sido mapeado hacia Source (Fuente), ya que Greenstone tiene su propio metadato Fuente, sino a un nuevo campo llamado MarcSource; y el campo 546 (\"Idioma\") ha sido mapeado hacia MarcLanguage.
Algunos campos MARC con contraparte en Dublin Core simplemente se han ignorado, p. ej. el 620 (Colaborador) y 500 (Cobertura). El campo 260 de MARC se llama \"Publicación, etc.\" y ha sido mapeado en su totalidad hacia Editorial. De hecho, se supone que el campo 260c (un subcampo) es la fecha de publicación, pero no se ha mapeado como tal.
Sin duda se pueden definir diferentes mapeos alterando los archivos que se indican arriba y que le permiten al plugin de MARC dar soporte a otras variantes del formato MARC. El plugin no reconoce subcampos MARC individuales, simplemente los concatena. Sin embargo, mejorarlo para que trate de forma adecuada los subcampos no debería ser una tarea difícil. Esto implicaría alterar un par de páginas de código PERL en el plugin de MARC. " # -- Russian text ---------------- collectionmeta collectionextra [l=ru] "This collection, which contains _about:numdocs_ MARC entries, is based on the MARC records of working papers published by Computer Science Department at the University of Waikato. Здесь представлен типовой документ данной коллекции.
Конфигурационный файл использует плагины ZIPPlug и MARCPlug, помимо третьего стандарта. Имеются три классификатора, основанные на метаданных Названия (Title), Создателя(Creator) и Предмета (Subject). Все они являются классификаторами AZCompactList и все определяют mingroup 1. Это вынуждает их создавать иконку книжной полки, даже в том случае, если имеется только один предмет на полке (подобно показанному здесь). Причина этого чисто эстетическая: список выглядит однородным, все предметы смотрятся одинаково, включая и единственную книгу. В том случае, если Вы не любите этот стиль, просто пропустите параметр mingroup. Второй параметр для классификаторов Название и Создатель удаляют суффиксы из строки метаданных (Название и Создатель, соответственно). Это требует установки PERL для правильного выражения, и урезает знаки (типа конечных знаков препинания) из строки для отображения. Три параметра формата являются сходными: в частности каждый из них выводит число документов в листе на правую строну дисплея, что Вы можете видеть здесь.
Плагин MARC использует специальный файл для сопоставления номера поля в MARC и метаданных Greenstone. Этот файл находится в директории gsdl/etc и называется marctodc.txt. Он представляет список соответствия между номерами полей системы MARC и метаданными Greenstone. �юбые поля MARC, которые не внесены в список, просто не появляются как метаданные, хотя они присутствуют в документе Greenstone. Каждая строка в этом файле имеет следующий формат.
<MARC field number> --> GreenstoneMetadataNameСтроки в данном файле, которые начинаются со знака \"\#\", являются комментариями (однако, комментарии могут быть удалены из распечатки, данной ниже).
Стандартная версия этого файла свободно базируется на MARC в описании Dublin Core, которое воспринимает USMARC/MARC21 и которое можно найти на http://lcweb.loc.gov/marc/dccross.html. Он содержит следующие строки:
gsdl/etc/marctodc.txt
\n
720 --> Создатель
\n
100 --> Создатель
\n
110 --> Создатель
\n
111 --> Создатель
\n
520 --> Описание
\n
856 --> URL
\n
260 --> Издатель
\n
787 --> Отношение
\n
540 --> Права
\n
024 --> Идентификатор MARC
\n
786 --> Источник MARC
\n
546 --> Язык MARC
\n
650 --> Предмет
\n
653 --> Предмет
\n
245 --> Название
\n
655 --> Тип
Несколько различных полей формата MARC внесены в Creator Dublin Core. Поле 720 -- «Неконтролируемое имя», 100 -- «Персональное название», 110 -- «Корпоративное название», 111 -- «Название встреч». Фактические записи в формате MARC обычно определяют только одно из этих полей, тем более, что Greenstone допускает многозначные метаданные.
Поле MARC 520 («Резюме, обратите внимание»), внесено в Описание (Description) Dublin Core, поле 856 («Электронное местоположение») соотнесено к URL; поле 787 («Неспецифическая запись отношений») к Отношению; поле 540 («Примечание о воспроизведении») к Правам; поле 245 («Оператор Названия») к Названию; поле 655 («Индексный термин -- жанр/форма») к Типу. Оба поля 650 («Предмет: тематический термин») и 653 (« Индексный термин: неконтролируемый») отнесен к Предмету.
Поле MARC 024 («Идентификатор») не сопоставлено с метаданными Greenstone, потому что в Greenstone используются собственные метаданные. Идентификатор; вместо этого различным метаданным Greenstone сопоставлен элемент MARC, называемый MarcIdentifier. Аналогичным образом поле 786 («Дата ввода источника») не отнесена к Источнику, потому что Greenstone имеет метаданные Источник, но взамен этого введено новое поле метаданных, названное MarcSource, а также и поле 546 («Язык») обозначено как MarcLanguage.
Некоторые поля MARC c эквивалентами Dublin Core просто игнорируются, например 620 (Участник) и 500 (Охват). Поле 260 в MARC называют «Публикацией» и т.д.» и ему в соответствие поставлено Издатель. Фактически поле 260 с (подполе) должно означать дату публикации, но в таком виде оно не включено.
Конечно, различные соответствия могут быть определены путем изменения вышеупомянутого файла, что позволяет плагинам поддерживать другие варианты формата MARC. Плагин не распознает индивидуальные подполя MARC: он просто связывает их вместе. Однако, доведение его до такого уровня, чтобы иметь дело непосредственно с подполями, не было бы трудной работой: надо было бы изменить несколько страниц программы PERL в плагинах MARC."