UNIMARC & FRIENDS

CHARTING THE NEW LANDSCAPE

OF LIBRARY STANDARDS

 

INTRODUCTION

 

Lors de la conférence internationale des 20 et 21 mars 2006 à Lisbonne, il a été question de faire le point sur l’utilisation du format UNIMARC, sur ses évolutions possibles et souhaitables, en suivant de près les progrès effectués dans ce domaine par l’IFLA. Plusieurs conférenciers ont présenté leurs expériences et leurs projets dont les résumés sont proposés dans ce compte-rendu. La préoccupation majeure de ces rencontres est de nourrir l’entente des utilisateurs d’UNIMARC, de permettre la « conversation » entre les systèmes qui doivent utiliser un format commun malgré les exigences locales marquées par des besoins d’utilisateurs auxquels les catalogues et bases de données bibliographiques s’adressent et pour lesquels il faut soigner la lisibilité et l’accès des données.

 

JOHN D. BYRUM

 

Chair, ISBD Review Group

Former Chief, Regional & Cooperative Cataloguing

Library of Congress

USA

 

TITLE : IFLA's EVOLVING PROGRAM TO PRODUCE AND PROMOTE THE INTERNATIONAL STANDARD BIBLIOGRAPHIC DESCRIPTIONS : PAST, PRESENT, and FUTURE.

The concept of the International Standard Bibliographic Description has now endured for more than 35 years and has proved to be IFLA’s most successful effort at promoting the cause of cataloguing standardization. This presentation will cover the origins, purposes, and coverage of the ISBDs. Also described are the procedures by which the ISBDs are maintained as well as the principal goals of the work to update them during the last quarter of the 20th century, a turbulent period in the history of libraries, publication patterns, and user expectations. Finally, the current priorities and activities of the ISBD Review Group are highlighted, in particular the initiative now underway to produce a consolidated version of the ISBDs

 

Le travail sur l’ISBD ne doit pas être vu comme un anachronisme, au contraire, car il fixe le but que la définition UNIMARC doit permettre d’atteindre. A l’origine, l’ISBD devait déboucher sur une automatisation du contrôle bibliographique. Il est rapidement devenu une nécessité économique (dans un contexte de catalogage partagé). En effet, il a permis de faciliter la « conversation », permet de surmonter la barrière des langues. Mais l’enjeu aujourd’hui est d’en faire une adaptation électronique, d’où la nécessité de l’intégrer aux problématiques de l’UNIMARC. Pour tout ce qui concerne la description des ressources électroniques, il est intéressant de consulter le site de l’IFLA, notamment la page qui concerne l’ISBD(ER) http://www.ifla.org/VII/s13/pubs/isbd.htm

La première révision propose d’harmoniser l’existant (aujourd’hui par exemple, une terminologie commune semble être adoptée : le terme global de « ressource » est préféré), d’enrichir par des exemples et d’accommoder les écritures non latines. La seconde raisonne sur la relation entre l’ISBD et les FRBR (BLNBR = Basic Level National Bibliographic Record). Le groupe de travail sur l’ISBD définit comme priorité la description matérielle (en créant une description séparée chaque fois qu’une œuvre est fixée sur un support différent) et la consolidation de l’actuel format, de façon à « faire se rencontrer les utilisateurs de catalogues et les utilisateurs de bibliographies ».

L’environnement électronique est perçu comme une nouvelle opportunité, et la fréquentation  de l’OPAC change les attentes des utilisateurs. Pour les évolutions à venir, le groupe propose la façon de travailler suivante : création d’un texte brouillon (draft), revue mondiale, révision finale, ballottage, publication. Pour la révision de l’ISBD (A), les commentaires sont attendus jusqu’au 1er mai (voir http://www.ifla.org/VII/s13/pubs/Invitation4WWreview2-22-06.htm).

 

Il faut noter que l’AFNOR propose une déclinaison française de l’ISBD, et que « toute révision des ISBD entraîne une révision des normes AFNOR ».

 

 

BARBARA B. TILLETT

 

Chief, Cataloguing Policy & Support Office

Chair of  IFLA Division IV: Bibliographic Control

 Library of Congress.

 

USA

 

TITLE : FUTURE CATALOGUlNG PRINCIPLES AND CODES : IFLA’s CATALOGUING PRINCIPLES (IME ICC MEETINGS) AND RDA (RESOURCE DESCRIPTION AND ACCESS)

ABSTRACT : The series of IFLA Meetings of Experts on an International Cataloguing Code (IME ICC) was established to reach worldwide agreement on updated cataloguing principles for today's Web environment. Like their predecessor, IFLA's Paris Principles of 1961, these new principles will form the foundation for every cataloguing code used in the world today. The case study of the new cataloguing code, RDA (Resource Description and Access), demonstrates the increased support for internationalization of cataloguing codes to facilitate the sharing of bibliographic and authority information worldwide and to reduce cataloguing costs worldwide and to improve the user's experience in finding, identifying, selecting ,and obtaining bibliographic resources of all types.

 

Barbara Tillet a livré à l’occasion de ce meeting sa propre vision du futur travail de catalogage, et propose une réflexion autour de l’éclatement de l’actuel format sur plusieurs plans. Après un bref historique des pratiques du catalogage et en particulier de ce qui a donné naissance de formats standards : Principes de Paris (1961), l’unification d’un format anglo-américain (1967), le développement de l’ISBD (1969), qui ont conjointement débouché sur l’AACR2 (= Anglo-American cataloguing Rules. – 2e édition, de 1978 à 2002), on entre rapidement dans une problématique pluri-dimensionnelle liée à l’introduction de l’outil informatique qui permet une lecture non linéaire des catalogues. C’est précisément la réactualisation et l’élargissement des principes de Paris qui constitue l’objectif des IME ICC qui ont lieu depuis 2003.

IME ICC1: http://www.ddb.de/standardisierung/afs/
IME ICC2: http://www.loc.gov/loc/ifla/imeicc/imeicc2/
IME ICC3: http://www.loc.gov/loc/ifla/imeicc/
IME ICC4: http://www.nl.go.kr/icc/icc/main.php

Les prochaines réunions vont avoir lieu à Séoul en 2006, à Durban en 2007. Ces rencontres de catalogueurs experts visent bien l’élaboration de standards internationaux. Cela a permis l’approbation des FRBR et FRAR (puis certainement bientôt les FRSAR = Functional requirements for Subject Authority Records), qui valident des règles de descriptions à tous types de matériels (alors qu’elles étaient appliquées au seul texte selon les Principes de Paris).  En outre, il semble important d’élargir les standards de description et de fournir davantage de renseignements sur l’accès aux ressources, d’où la création d’un code de catalogage, RDA (Resource description and Access) qui vise la mise en œuvre effective des FRBR tout en se conformant aux principes en vigueur ; son déploiement prévu pour 2008. Cependant, les FRBR sont un « modèle conceptuel », ce qui rend difficile à imaginer leur application concrète. Voici un schéma de ce modèle :

On peut voir émerger le rôle de la notice d’œuvre (‘work’) qui est une façon de décrire le contenu en le séparant de la notion de document, ce qui aboutit à une gestion par des notices séparées. Celui-ci respecte, comme l’ont fixé les groupes de travail de l’IFLA, la charte du catalogue qui permet « de trouver, d’identifier, de sélectionner et d’obtenir » l’information souhaitée.

Une évolution de ce schéma est déjà prévue pour éviter l’occurrence redondante de la mention de responsabilité dans chaque « notice d’œuvre » et dans chaque « notice d’expression », en s’appuyant sur trois étapes de la modélisation  bibliographique : les « entités », les « relations » et les « attributs ». Les futures évolutions sont en cours de discussion :

- Oct 2005- avril 2006 : description de la ressource

- Mai – sept. 2006 : relations

- Oct 2006 – avril 2007 : Contrôle d’autorités

[…]

Il faut trouver un modèle qui convienne à la fois à l’UNIMARC et au MARC21.

La stricte application des FRBR permet le partage global de l’information bibliographique, et aide évidemment à la réduction des coûts. L’IFLA reste consciente qu’une grande partie des bibliothèques dans le monde utilise les formats de données qu’elle préconise, mais que chacun souhaite conserver ses spécificités ; il faut donc permettre de composer avec l’environnement web d’aujourd’hui tout en maintenant les exigences du travail de signalement traditionnel dans les bibliothèques, les archives et les musées.

 

 

PATRICK LE BOEUF

 

Bureau de Normalisation Documentaire

Former Chair

 FRBR Review Group

 Bibliothèque Nationale de France

 

TITLE : MODELLING BlBILIOGRAPHIC DATA: PURPOSES, PROSPECTS, POTENTlAL

ABSTRACT : The library community has by now become "accustomed" to having. a conceptual model for the bibliographic data it produces, namely FRBR (Functional Requirementsfor Bibliographic Records). But what is the use of creating a conceptual model of that kind? There has been a shift over time from what were the initial purposes of FRBR to the cur­rent trend that focuses on the model's potential for use with semantic web technologies. The future directions for FRBR include, on the one hand: an extension of the field covered by the model, on the other hand: efforts towards an accurate expression of FRBR concepts in RDF (Resource Description Framework), for bibliographic data to become available for other applications than just library catalogues, on the broader Semantic Web. Finally, conceptual models for data from different domains within the universe of cultural heritage information can serve as tools for achieving the goal of making such domains converge: for instance, FRBR is getting aligned with the museum community's semantic model CI­DOC CRM (ClDOC Conceptual Reference Model), and the UNIMARC format has been mapped to CIDOC CRM.

 

 

L’enjeu aujourd’hui pour les bibliothèques est de pouvoir intégrer leur travail de catalogage, de signalement, voire de diffusion, à la trame du Web, et ne pas laisser dans l’ombre leurs bases de données structurées et alimentées par des professionnels de l’information. Ceux-ci, d’ailleurs, en utilisant les FRBR, pourront justifier leurs descriptions et leurs choix avec plus de souplesse, et enrichir plus efficacement une base de connaissances commune. Le contexte RDF (Resource Description Framework ; voir pour plus d’information la recommandation W3C de 1999 http://www.w3.org/TR/rdf-concepts/) conduit les données contenues dans les catalogues à s’inspirer du Web sémantique, qui peut être considéré comme un « successeur de l’Intelligence Artificielle ».

Patrick Leboeuf cite en exemple le modèle sémantique de référence CiDOC-CRM (http://cidoc.ics.forth.gr/) voir la définition sur le site de la BnF : « Le modèle CRM vise fondamentalement à fournir un langage commun à des gisements d'information hétérogènes et à permettre leur intégration, par delà leurs éventuelles incompatibilités tant sémantiques que structurelles. Il s'agit donc de faciliter l'échange et la recherche d'informations dans le domaine du patrimoine culturel et de permettre aux musées de rendre compatibles leurs documentations sans rien perdre de leurs spécificités ni du niveau de précision de leurs données actuelles. »

 

L’information bibliographique doit-elle être  « Web-sémantisée » ?

 

GLENN E. PATTON

 

Director, WorldCat Quality Management Division, OCLC Chair,

IFLA Working Group on Functional Requirements and

Numbering of Authority Records

USA

 

TITLE : EXTENDlNG FRBR CONCEPTS TO AUTHORlTY DATA

ABSTRACT : Over the past several years, the IFLA Working Group on Functional Requirements and Numbering of Authority Records has been working to develop a conceptual model that will provide a framework for the analysis of how authority data functions. A draft of the model was made available for worldwide review from July through October 2006. This paper will describe the current state of the conceptual model and how the results of the worldwide review are being incorporated into a new draft.

 

Le but de ce travail est de définir des spécifications fonctionnelles pour les notices authorités en « étendant les concepts du FRBR aux données d’autorités ».  La dernière fonction de l’autorité est de lier la notice la notice autorité à la notice bibliographique, et permettre à l’utilisateur de « trouver, identifier, contextualiser et justifier » un résultat.  Un exemple permet de voir comment s’articule la relation entre les entités bibliographiques, les noms (et/ou les identifiants), et les point d’accès contrôlés :

 

Poe, Edgar Allan. The Fall of the House of Usher

...

see also

Debussy, Claude. La chute de la maison Usher

 

C’est un exemple qui montre la relation sous-jacente entre les autorités grâce à l’introduction du découpage Oeuvre/Expression/Manifestation.

La publication des résultats est prévue en octobre 2006.

 

 

 

MIRNA WILLER

 

Member of the IFLA FRANAR Working Group

National and University Library

Zagreb

Croatia

 

TITLE : IFLA UBCM WORKlNG GROUP ON FRANAR - RECOMMENDATIONS FOR POTENTIAL CHANGES lN UNIMARC AUTHORITIES FORMAT

       ABSTRACT : ln the process of developing a conceptual model for Functional Requirements for Authority Records (FRAR) the IFLA UBCM Working group on FRANAR examined data and structures defined in IFLA documents FRBR, GARR, UNlMARC/Authorities

and Mandatory Data Elements for Internationally Shared. Authority Records (MLAR), and subsequently identified fields for potential changes in those documents.

The paper will describe recommendations made for potential changes in UNIMARC Authorities Format. These changes broadly include:

-Reference records : Consider whether reference records are still needed. Perhaps a survey would be useful. Recommendation : survey should be performed together with GARR and MARC 21.

-All heading fields : Issue of whether "entry element" as defined in UNIMARC is equivalent to "Base access point" attribute defined for Access points in FRAR.

-Field 101 (Language of the Entity): May need further clarification that this is the

                  same as the FRAR attribute of Work, Original language of the work.

-Field 102 (Nationality of entity); Consider attributes regarding this data.

-Field 220 (Family name) : A subfield or other indicator for Type of family may be

                  needed.

-Field 7XX, $2 (Subject System Code) : This needs to be expanded to cover catalogu­ing rules to be represented as subject systems are (parallel to field 152).

 

Les notices autorités ont besoin d’évoluer pour permettre une description plus précise qui porte sur des éléments pertinents. On s’interroge aussi sur le degré d’interprétation effectué par le catalogueur (c’est-à-dire utiliser des éléments qui n’appartiennent pas au document en lui-même), à partir des recommandations pour des changements potentiels dans le format d’autorités UNIMARC, et dans FRAD, qui sont assez différents , en particulier sur les points suivants :

 

les notices de référence

Les notices de références sont elles toujours utiles ? Pour le savoir, il faudrait faire une enquête chez les utilisateurs de GARR et MARC21. En effet, les formes retenues et les formes dérivées peuvent être mentionnées dans la notice autorité ;

 

le point d’accès de la base

Dans les FRAD l’entrée inclut  le nom d’une personne, le titre d’une personne (nobiliaire, ecclésiastique), un élément du titre pour une oeuvre, un terme désignant la forme pour une oeuvre musicale (ex. Symphonie, concerto).

Pour UNIMARC :

Considérons l’exemple suivant :

200#1$aNicolini da Sabio$bDomenico$f15..-160. ?$cimprimeur-libraire

La langue du titre est l’italien, la langue de catalogage le français : le qualificatif est exprimé en français...

 

la langue de l’entité

Le champ 101 devrait pouvoir prendre en compte un attribut de l’expression et accueillir un qualificatif sur la langue originale, ce qui n’est pas le cas, alors que l’on peut y mentionner la nationalité. Pour les FRAD la langue est un attribut de :

- la personne : la langue qu’une personne utilise au moment où elle écrit l’oeuvre,

- l’oeuvre, l’expression : la langue dans laquelle l’oeuvre a été exprimée la première fois,

- l’expression : la langue dans laquelle l’oeuvre est exprimée ;

 

la nationalité de l’entité,

Le champ 102 : UNIMARC contient un code pour la nationalité, la résidence, le siège social, le lieu de composition de l’oeuvre. Les FRAD, les attributs sont :

- Pour une personne : lieu de naissance, de décès, le pays, lieu de résidence

- Pour une famille : les lieux associés à celle-ci,

- Pour une oeuvre : lieu d’origine de l’oeuvre,

- Pour une manifestation : lieu de la publication ;

 

le nom de famille

On a besoin de définir quels éléments permettent de qualifier. Le champ 220 doit faire l’objet de clarifications : il prévoit le sous-champ $a et $f, mais il faudrait pouvoir y ajouter des éléments tels que le type de famille, les dates, et les lieux associés à la famille, comme dans les FRAD.

Ex. : 220##Shah$cdynasty$f1768-...

 

le lien entre le bloc principal et le sujet

Le champ 7XX $2[code système] demande à être pris en compte dans un contexte international, et non pas renvoyer uniquement à l’autorité en vigueur dans le pays de catalogage !

 

les relations entre les différents entités

Les FRAD prennent en compte les relations entre autorités :

- de le personne à la famille : relations de familles,

- de la personne à la collectivité

UNIMARC mentionne les relations en 5XX $5

 

 

VLADIMIR SKVORTSOV

 

Automation Department

National Library of Russia (Saint-Petersbourg)

 

TITLE : UNIMARC'S EMBEDDED FIELDS AND MARCXCHANGE. UNEXPECTED PLOT.

ABSTRACT : It should deal with the principles of transformation ISO 2709 to XML Slim. That is in topic while creating new ISO 25577 Standard. In author's opinion the straight emula­tion of ISO 2709 is not the best way to build a transport XML schema because, in this case, the potential possibilities of XML slim is lost for embedded fields. Some expansion of the Standard is needed. The author suggests a solution, which seems to be in accordance with all existing MARC formats.

 

La présentation complète est disponible sur le Web en format *.pdf : http://www.rba.ru/rusmarc/rusmarc/updates/UNIMARC_XML.pdf.

 

Cet exposé nous intéresse particulièrement car il montre les problèmes qui sont liés à la transformation et à l’échange de données d’iso2709 à XML. Bien que cela semble approprié, certains problèmes inattendus se manifestent rapidement, notamment pour ce qui concerne les zones et les sous-zones imbriquées (voir Manuel UNIMARC, p. 207-212).

 Premier cas recensé :

451#0$1001BLN6956090$12001#$aPrefaces to the experiences of literature
$1210##$aNew York$cHarcourt Brace Jovanovich$d1979

 

donne, après transformation XML :

 

<datafield tag="451" ind1=" " ind2="0">

<subfield code="1">001BLN6956090</subfield>

<subfield code="1">2001 $aPrefaces to the experiences of

literature</subfield>

<subfield code="1">210  $aNew York$cHarcourt Brace

Jovanovich$d1979</subfield>

</datafield>

Comment interpréter la valeur indiquée après $1 autrement que par une analyse sémantique ?

La question est essentielle car il faut développer des solutions, souvent « non-standard » dès lors que l’on choisit de travailler en XML. Si l’on considère le succès du logiciel libre, cela multiplie les particularités locales, et l’on n’est pas sûr qu’une révision de la norme puisse être prise en compte systématiquement par les systèmes informatiques. Il est à craindre que dans ces conditions, la technique des zones imbriquées ait donc peu de chances de survivre.

 

Deuxième surprise : le code de séparateur de sous-champs hexadécimal 1F (qui se manifeste par un $ dans une notice UNM) n’est pas employé dans la chaîne XML alors que selon la recommandation W3C, il devrait l’être.

 

Enfin autre cas de zone imbriquée laissée pour compte par XML : un champ presque oublié, qui est le 886 (Zones de données du MARC étranger).

Ex :

- 886 2#$2ukmarc$a083$b00$aRussia. Education$b- Biographies - Collections

(Example from UNIMARC Manual)

- 886 2b¹2ukmarc¹a690¹b00¹a00030¹dGreat Britain¹z11030¹abatterflies¹z21030¹alife cycles

(Example from USMARC Manual)

Qui se traduirait respectivement ainsi d’après le schéma XML Slim (voir les travaux à ce sujet : http://www.ifla.org/IV/ifla71/papers/064e-Skvortsov.pdf) :

 

   <datafield tag="886" ind1="2" ind2=" ">

      <subfield code="2">ukmarc</subfield>

      <subfield code="a">083</subfield>

      <subfield code="b">00$aRussia. Education$b- Biographies - Collections</subfield>

   </datafield>

 

   <datafield tag="886" ind1="2" ind2="b">

      <subfield code="2">ukmarc</subfield>

      <subfield code="a">690</subfield>

      <subfield code="b">00¹a00030¹dGreat Britain¹z11030¹abatterflies¹z21030¹alife cycles

</subfield>

   </datafield>

 

On observe immédiatement que les codes de sous-champ sont inclus dans le corps de données XML : le champ 886 lui non plus ne supporte donc pas la transformation XML…

 

Solutions (ou propositions) :

Pour le moment un groupe de travail se penche sur XML Slim (Oslo, Août 2005) qui est en conformité avec le cahier ISO/DIS 27577 en cours de révision. Par exemple, pour donner un aperçu de ce travail, au cas évoqué premièrement, nous pouvons appliquer ce schéma :

<built-in tag="451" ind1=" " ind2="0"> <control tag="001">BLN695609</control>

<datafield tag="200" ind1="1" ind2=" ">

<subfield code="a">Prefaces to the experiences of

literature</subfield>

</datafield>

<datafield tag="210" ind1=" " ind2=" ">

<subfield code="a">New York</subfield>

<subfield code="c">Harcourt Brace Jovanovich</subfield>

<subfield code="d">1979</subfield>

</datafield>

</built-in>

 

JOSE BORBINHA, HUGO MANGUINHAS, NUNO FREIRE

 

Researchers, INESC-ID

Consultants National Library of

Portugal

 

TITLE : UNIMARC AND XML - AN ANALYSIS

Abstract: This paper presents an analysis of the multiple relationships between UNIMARC and XML. One scope is the representation of UNIMARC records in XML files, as an alternative to, for example, ISO2709. This should be addressed consider­ing the already existing MARCXML schema, promoted by the MARC21 community and compatible with the UNIMARC in general, but a detailed analysis is required. Another scope is the formal description of the UNIMARC itself as a family of formats and the rel­evance of a XML schema (or family of schemas) able to accommodate the formal syntaxes, semantics and mu1tilingual textual descriptions to be interpreted by both machines and humans. This is related with the UNIMARC Metadata Registry, to be defined according to the ISO/IEC 20944 series of standards for metadata registry interoperability and bind­ings, as also to the definition of a required URN space for the UNI MARC elements. Fi­nally, we discuss also the relations between theses two perspectives and also to MARC21, in order to define a possible unified conceptual space for the description of the formats and also the coding of the records.

 

Cette présentation montre les rapports multiples et complexes d’UNIMARC et d’XML. Le but est de permettre un affichage rapide dans différents formats. Beaucoup de projets sont en cours et l’enjeu consiste à permettre aux bibliothécaires de conserver les spécificités de leur travail, la valeur ajoutée aux documents traités tout en s’adaptant à l’environnement Web : « Le danger est de laisser UNIMARC évoluer dans une direction qui n’a rien à voir avec nos préoccupations ». Pour se faire une idée des applications concrètes - car c’est un groupe de chercheurs (notamment de l’INESC, Instituto de Engenharia de Sistemas e Computadores) et de consultants qui doivent fournir des solutions pratiques, il faut consulter l’url http://urn.porbase.org/lingua.do?lingua=en.

 

 

 

 

En voici un exemple :

 

ISBD

[3]                                     P. 5166 V.

RIBEIRO, Orlando, 1911-1997
O Brasil : evolução no Império Português / Orlando Ribeiro. - Coimbra : Inst. de História Económica e Social, 1978. - p. 232-243, [1] p. ; 24 cm. - Sep. Rev. Port. História, 17

CDU 008(042)

 

UNIMARC

Etiqueta de registo: 00604cam 02200205 04500
001 3
005 20020701015800.0
095 ## $aPTBN00000003
100 ## $a19790701d1978 m y0pora0103 ba
101 0# $apor
102 ## $aPT
200 1# $a<O >Brasil$eevolução no Império Português$fOrlando Ribeiro
210 ## $aCoimbra$cInst. de História Económica e Social$d1978
215 ## $ap. 232-243, [1] p.$d24 cm
305 ## $aSep. Rev. Port. História, 17
675 ## $a008(042)$vBN$zpor$vmed$zpor$3287994
700 #1 $aRibeiro$bOrlando$f1911-1997$321406
801 #0 $aPT$bBN$gRPC
966 ## $lBN$mMG$sP. 5166 V.
998 ## $aFSE01 - 00003

 

MARCXML

<?xml version="1.0" encoding="UTF-8" ?>

- <collection xmlns="http://www.bn.pt/standards/metadata/marcxml/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bn.pt/standards/metadata/marcxml/1.0/ http://xml.bn.pt/schemas/Unimarc-1.0.xsd">

- <record>

  <leader>00604cam 02200205 04500</leader>

  <controlfield tag="001">3</controlfield>

  <controlfield tag="005">20020701015800.0</controlfield>

- <datafield ind1="" ind2="" tag="095">

  <subfield code="a">PTBN00000003</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="100">

  <subfield code="a">19790701d1978 m y0pora0103 ba</subfield>

  </datafield>

- <datafield ind1="0" ind2="" tag="101">

  <subfield code="a">por</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="102">

  <subfield code="a">PT</subfield>

  </datafield>

- <datafield ind1="1" ind2="" tag="200">

  <subfield code="a"><O >Brasil</subfield>

  <subfield code="e">evolução no Império Português</subfield>

  <subfield code="f">Orlando Ribeiro</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="210">

  <subfield code="a">Coimbra</subfield>

  <subfield code="c">Inst. de História Económica e Social</subfield>

  <subfield code="d">1978</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="215">

  <subfield code="a">p. 232-243, [1] p.</subfield>

  <subfield code="d">24 cm</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="305">

  <subfield code="a">Sep. Rev. Port. História, 17</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="675">

  <subfield code="a">008(042)</subfield>

  <subfield code="v">BN</subfield>

  <subfield code="z">por</subfield>

  <subfield code="v">med</subfield>

  <subfield code="z">por</subfield>

  <subfield code="3">287994</subfield>

  </datafield>

- <datafield ind1="" ind2="1" tag="700">

  <subfield code="a">Ribeiro</subfield>

  <subfield code="b">Orlando</subfield>

  <subfield code="f">1911-1997</subfield>

  <subfield code="3">21406</subfield>

  </datafield>

- <datafield ind1="" ind2="0" tag="801">

  <subfield code="a">PT</subfield>

  <subfield code="b">BN</subfield>

  <subfield code="g">RPC</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="966">

  <subfield code="l">BN</subfield>

  <subfield code="m">MG</subfield>

  <subfield code="s">P. 5166 V.</subfield>

  </datafield>

- <datafield ind1="" ind2="" tag="998">

  <subfield code="a">FSE01 - 00003</subfield>

  </datafield>

 

 

Les familiers de WinIBW y verront des fonctionnalités similaires en ce qui concerne l’affichage des notices dans différents formats...

 

Il semble donc que le schéma MARCXML, validé par MARC21, soit aussi compatible avec UNIMARC (des vérifications plus approfondies doivent être effectuées), ce qui rend possible d’imaginer un pont entre les deux familles MARC. La préoccupation première est de créer un espace de données interprétables à la fois par les humains et les machines.

 

 

 

GIOVANNI BERGAMIN

 

Responsible for Information & Technology Services

Biblioteca Nazionale Centrale Firenze

Italy

TITLE : A NEW OPAC FOR BNCF USlNG OPEN SOURCE SOFTWARE, XML AND UNlMARC

ABSTRACT : A new interesting opportunity js now emerging in software for libraries: the open source option. When two years ago we staded to plan a new OPAC for BNCF We spent a considerable amount of time in searching open source solutions ready to be "reused" in our lihrary (of course with some "small adaptations"...).

Unfortunately the summary of our findings was:

·        there is a lot a valuable open Source software for the so called "digital library infrastruc­ture", but this infrastructure, does not include a "suitable" OPAC for BNCF;

·        the available open source solutions for an OPAC…

·        …offer a limited support for MARC records (Namely UNIMARC records)…

·        …usually present "an interface that only a librarian could love" [R. Tennant, 2005]"

The paper will present the results of our project : a new OPAC based on open source system and programming software;

  • UNIMARC records expressed in XML syntax (based on MARCXML syntax, but with full support of embedded fields technique) ;
  • A new "post-Google  interface.

 

Lorsqu’il a fallu choisir un logiciel pour le catalogue de la BNCF (http://catalogo.bncf.firenze.sbn.it/cgi-opac/opac.cgi?Lingua=ITA&unicode=F), trois critères émergeants ont permis de choisir une solution qui soit :

- un système open source ;

- un système de gestion des notices en UNIMARC exprimées dans une syntaxe XML(en réalité MARCXML, mais qui supporte les zones imbriquées)

- une interface « post-google ». Ce retour d’expérience nous montre une adaptation du libre qui convient  à des contraintes particulières.

 

 

CONCLUSION

 

 

Cette rencontre a été le lieu de nombreuses discussions et réflexions autour du format UNIMARC et de son avenir. Il faut voir dans l'UNIMARC un moyen efficace de permettre la « conversation » entre les bases de données catalographiques et bibliographiques, mais il a besoin d'un support qui lui permette de « traverser» le Web, d'intégrer la toile sans subir une influence nuisible à nos préoccupations bibliothéconomiques. En effet, il semble que le format XML permette de décliner les possibilités d'UNIMARC, mais il faut prendre garde à ne pas perdre le caractère pluri-dimensionnel du format documentaire. L'évolution des formats sur le Web, l'évolution des services - accompagnée de l'évolution des attentes et des exigences de l'internaute - a donné naissance à une profusion grandissante de formats qui voudraient tous être standards (!), pas toujours normalisés ni suivis, qui sont autant de « tentatives », mais il faut attendre un certain temps avant qu'un format soit validé.

L'exemple de Dublin Core est assez parlant. Selon Sally McCallum (Responsable d'un département de catalogage de la Library of Congress) : « devant les volumes énormes de données, les besoins évoluent », et « MarcXML aussi bien que MarcXchange (ISO/DIS 25577) ne sont que des solutions immédiates ». MODS (Metadata Object Description Schema) est « plus simple que Marc21 et plus riche que DublinCore » mais repose sur un développement ouvert, et chaque adjonction d'étiquettes concerne nécessairement des données non susceptibles d'être exportées au niveau international. Cette problématique est valable aussi pour les documents en format numérique, mais le problème de la pérennité des informations s'y ajoute, ainsi que la transmission, c'est pour cela qu'il faut considérer le standard METS (Metadata Encoding & Transmission Standard; voir sur cet aspect le Bulletin de l'ASIS&T :

http://www.asis.org/Bulletin/Dec-02/guenthermccallum.html). Le protocole Z39-50 est lourdement sollicité et se voit complété par SRU et SRW qui améliorent la méthode HTTP GET/POST en se calquant sur l'architecture SOAP. C'est le développement d'un Web-Service. Nous pourrions créer un groupe de travail à ce sujet et surveiller l'évolution des produits que nous utilisons afin de les orienter dans ces nouvelles directions.

 

D'autres projets internationaux ont vu le jour: il est intéressant de suivre de près les résultats des recherches menées par l'IFLA, car de nouvelles relations s'établissent à l'échelle européenne et mondiale (voir par exemple ICABS:

http://www.ddb.de/wir/operation/icabs.htm) Ces projets supposent tous une réflexion autour de la relation entre UNIMARC et XML, format mieux connu des développeurs aujourd'hui que les formats d'échange « classiques ». Dans un avenir proche, il faudra inciter les fournisseurs de livres à promouvoir les notices en UNIMARC, mais aussi multiplier les contacts avec les développeurs de systèmes et enfin, éditer un manuel UNIMARC-XML.

 

 

Les présentations des intervenants sont désormais disponibles :

http://unimarc.bn.pt/html/apresentacoes.html