FRBR, FRBRer et FRBRoo — et PRESSoo (tant qu’à faire)
Recontextualisation
Je me suis retrouvé à creuser le modèle FRBR (pour une formation Médial où j’ai croisé Manue au milieu de son tour de France), et j’ai découvert que ça a quand même un peu bougé depuis la toute première présentation qui m’en a été faite à l’Enssib en 2004.
Le modèle de base lui-même n’a pas changé (on a toujour des oeuvres/expressions/manifestations/items, reliées à des autorités/sujets) mais d’autres termes ont fait leur apparition, que j’ai eu du mal à situer l’un par rapport à l’autre : FRBRER et FRBROO.
Précision utile : je ne participe pas aux instances décisionnelles et autres groupes techniques qui développent les différents modèles de données évoqués ici. Ma compréhension s’en trouve forcément limitée. Si vous avez des éclairages complémentaires, voire des critiques face à mes erreurs d’interprétations et mes ignorances, n’hésitez pas !
FRBR (tout court)
Le modèle FRBR est né d’un groupe de travail de l’IFLA dans les années 1990.
L’objectif était de définir une nouvelle manière de concevoir l’information bibliographique en fonction des usages qui pouvaient être fait d’une notice bib. 4 usages ont été identifiés par le groupe (trouver/identifier/sélectionner/obtenir).
Par ailleurs le groupe a constaté que dans les pavés ISBD se trouvaient des informations qui relevaient de plusieurs niveaux, et notamment un mélange Contenu / contenant qui, surtout dans un contexte de catalogues informatisés (parce qu’à l’époque, il fallait préciser pour un catalogue qu’il était informatisé), n’avait aucune justification.
Exemple d’info sur le contenu dans le pavé ISBD : titre, auteur.
Exemple d’info sur le contenant : nombre de pages.
A partir de ces diverses constatations (et de quelques autres), le groupe a défini le modèle qu’on est censé connaître à peu près aujourd’hui, d’arbre FRBR.
Le vocabulaire FRBR
Pour exprimer et décrire cette structure, le rapport final du groupe de travail IFLA sur le FRBR (version française – PDF) utilise un vocabulaire cohérent :
- les blocs sont des entités(n’apparaissent ici que les entités du groupe 1)
- les entités ont entre elles des relations
(y compris des relations d’oeuvres entre elles, d’expressions entre elles, d’items entre eux) - chaque entité a également des attributs pour la décrire
(le code-barres est un attribut de l’entité Item, permettant de décrire l’exemplaire détenu par une bibliothèque spécifique)
Ces termes, entités, relations et attributs, sont récupérés du mode de représentation Entité-Relation (ou « Entité-Association« , puisque Wikipedia dit que c’est ainsi qu’il faudrait dire — mais tant pis).
Ce mode de représentation (ou modèle de données) permet de représenter l’information sous forme de diagrammes en attribuant à chaque objet du diagramme un terme avec un sens précis : entité (plutôt que « bloc », « ressource », ou « chose »), relation (plutôt que « trait », « lien »), attribut (plutôt que « champ » — mais on peut aussi parler de propriété).
Et le web des données dans tout ça ?
L’idée de structurer l’information en triplets, née dans le cerveau magistral de Tim Berners-Lee, arrive à la fin des années 1990. Elle sera prolongée et construite dans le cadre du W3C.
Le vocabulaire utilisé sera : Sujet – Prédicat – Objet
L’élaboration du modèle FRBR se fait donc de manière complètement indépendante. On le constate d’ailleurs quand on compare attributs et relations : par exemple dans ce diagramme qui s’intéresse à l’oeuvre Education européenne (premier roman de Romain Gary) et à son auteur.
Les « relations » (entre entités FRBR) sont en rouge, les attributs (de chaque entité) sont en bleu
Si on prend la peine d’y reconnaître un graphe avec quelques triplets, on constate que
- dans le modèle FRBR, « Auteur » est une relation et « Titre » est un attribut
- dans le modèle RDF, « Auteur est « Titre » sont tous deux des prédicats
- l’objet du prédicat « Auteur » est un URI
- l’objet du prédicat « Titre » est une chaîne de caractères
- par ailleurs, si je peux exprimer l’oeuvre et l’auteur par des URI, je n’ai pas d’URI à disposition pour désigner les prédicats « Auteur » et « Titre » tels que définis dans le modèle FRBR.
Bref, il faut ajuster le modèle FRBR pour le caler parfaitement sur la représentation en graphe RDF.
Les musées réfléchissent aussi (si !)
Dans les années 1990 également (c’est fou tout ce qui s’est passé à cette période, alors que je n’avais même pas mon bac ! On est peu de choses, finalement…), au sein de l’ICOM (le Conseil international des musées, l’IFLA des musées donc), la section chargée de la documentation, le CIDOC,définit un modèle de description de ressource (ressource muséale, donc) : le CRM.
Et puis tous ces gens se sont dit : et si on travaillaient ensemble ?
FRBRER et FRBROO
A la suite de ça est né le projet FRBROO : la fusion du CRM et du FRBR, adapté au contexte nouveau du web des données.
OO, c’est pour Orienté objet, terminologie plus informatique que Entité-Relation, qui n’envisage les choses que sous un angle purement conceptuel (et hors cadre technique).
Cela induit une manière différente d’exprimer les concepts manipulés. Ainsi, dans le modèle CRM, il n’y a pas d’attribut : il n’y a que des propriétés.
Par contre-coup, pour désigner le modèle FRBR initial, dans sa terminologie « Entité-relation », celui-ci se trouve rebaptisé FRBRER.
- C’est au sein de l’IFLA qu’a été conçu le modèle FRBR
- C’est au sein du W3C qu’a été développé le modèle RDF
- Pour le FRBROO, le groupe de travail FRBR de l’IFLA et le groupe CRM du CIDOC (ICOM) fusionnent en 2003
La première version de FRBROO date de 2008.
Une ontologie FRBR
Adapter le modèle FRBR au web des données, c’est donc
- définir l’ensemble des classes (ex-entités) et des propriétés (ex-relations + ex-attributs), leurs spécificités, etc. (ce qu’on peut relier ensemble ou non, etc.)
- Attribuer des URI à une classe ou un attribut
Pour pouvoir dire que http://data.bnf.fr/13505466/romain_gary_education_europeenne/ est du type FRBR oeuvre, il faut pouvoir disposer d’un URI pour le type oeuvre dans le modèle FRBR (qu’on pourrait abréger en frbr:work, par exemple) - Il faut aussi tenir évidemment compte de l’apport des musées, puisque le modèle FRBR initial est conçu pour des descriptions bibliographiques.
L’idée est d’anticiper aussi une éventuelle intégration d’autres modèles de descriptions (au hasard : archivistique – pourquoi pas ?)
Plusieurs documents ont été produits, permettant de définir ce modèle
- d’abord un « rapport » décrivant textuellement ce qu’on obtient.
Vous trouverez sur cette page la dernière version de mai 2013 [pdf]. - ensuite
un ensemble de schémas donnant des exemples de graphes types pour rendre compte de la structure obtenue
Work and Expression
- Enfin l’ontologie elle-même, exprimée en schémas RDF, dont plusieurs versions sont accessibles sur cette page [dernière version].
On y voit notamment que les deux premières classes définies sont celles de « Work » et de « Expression ».
PRESSOO
Pendant la journée Sudoc-PS à l’Abes (où la question a été abordée) l’élaboration du modèle PRESSOO, présenté succinctement ici, élaboré par l’ISSN et la BnF : le « oo » final permet de précise que c’est bien un prolongement de FRBROO et non du modèle FRBR initial (désigné FRBRER).
PRESSOO vient répondre à la question « Et Dieu les périodiques dans tout ça ? »
Principes de structuration FRBRisée d’un périodique et de ses fascicules (p. 6)
Donc il devrait devenir possible de faire rentrer les périodiques dans ce modèle. Évidemment, il faut se demander l’intérêt qu’on en tire, au regard des usages définis par le modèle FRBR pour les utilisateurs :
- trouver
- identifier
- choisir
- obtenir
Exemple : au sein d’un titre précis, le lien entre la revue papier et les différents accès à la revue en ligne (selon les plate-formes aggrégatives) sera sans doute plus perceptible.
Par ailleurs, la visualisation des titres qui fusionnent, qui « deviennent », qui meurent et renaissent de leurs cendres, etc. — bref, l’apparition de liens entre revues (au niveau de l’oeuvre) vont sans doute devenir plus intéressantes.
On peut supposer que cette modélisation qui est actuellement développée devrait à terme faire l’objet d’une validation par l’instance qui développe FRBROO , pour réintégrer in fine le modèle général.
Bref, voilà où il semble qu’on en soit :
Mise à jour du schéma
Suite aux remarques de P. Le Boeuf en commentaire, voici un schéma plus exact
Au fait
Voici ma présentation FRBR lors de cette formation.
Rien de bien original, et souvent abscons sans le discours prévu pour l’accompagner. J’ai tout de même pu profiter, sur les exemples d’applications FRBR, de la présentation d’OpenCat lors des Journées Abes 2013, et d’un billet paru le matin même de la formation sur le blog Punktokomo concernant theses.fr.
Trackbacks
- FRBR | Pearltrees
- FRBR, FRBRer et FRBRoo -- et PRESSoo (tant qu'&...
- FRBR, FRBRer et FRBRoo -- et PRESSoo (tant qu'&...
- FRBR, FRBRer et FRBRoo -- et PRESSoo (tant qu'&...
Commentaires fermés
Bibliothèques [reloaded] 
Un grand merci pour cette présentation très claire et très bien faite de l’articulation entre les différents modèles. Juste un tout petit détail : il est un chouïa exagéré de dire que le groupe FRBR de l’IFLA et le groupe CR de l’ICOM CIDOC ont « fusionné » en 2003 : en fait il s’est constitué un groupe de travail commun avec des membres de l’un et des membres de l’autre, mais il n’y a pas eu fusion des deux groupes, qui ont continué de mener leur vie chacun de son côté. Bon, vous me direz, ça ne change pas grand-chose, c’est juste histoire d’être pointilleux.
Un tout petit détail aussi concernant le dernier schéma, celui qui est introduit par la phrase « Bon, voilà où il semble qu’on en soit » : là encore, le mot « fusion » me fait un chouïa tiquer. En fait, FRBRoo est défini comme une extension du modèle CIDOC CRM, ce qui signifie que le modèle CIDOC CRM a sa propre existence autonome et peut très bien continuer d’être utilisé sans aucune référence à FRBRoo, en revanche FRBRoo ne peut pas être utilisé indépendamment du CIDOC CRM (ce qui contribue à le rendre difficile à lire). Toute classe définie dans FRBRoo est obligatoirement déclarée comme une sous-classe d’une classe du CIDOC CRM, toute propriété définie dans FRBRoo est obligatoirement soit déclarée comme une sous-propriété d’une propriété du CIDOC CRM, soit comme un « raccourci » de propriétés par ailleurs déclarées dans FRBRoo et/ou le CIDOC CRM (je ne sais pas si je suis bien clair…). Et de nombreuses notions « de base » sont en fait déjà exprimées au moyen de propriétés déclarées dans le CIDOC CRM qui ne sont donc pas répétées dans FRBRoo, ce qui oblige constamment à jongler entre FRBRoo et CIDOC CRM.
Dans la documentation relative à FRBRoo, on a effectivement utilisé la convention d’écriture « FRBRer » pour faire référence au modèle FRBR d’origine afin d’éviter les ambiguïtés, mais en dehors de ce contexte l’emploi de l’acronyme FRBR tout court renvoie par défaut à la version « entity-relationship » (je me mets à parler anglais pour éviter le dilemme « relation / association » 😉 du modèle FRBR. On ne peut donc pas tout à fait dire que le modèle FRBR a été « rebaptisé » FRBRer, ça a quelque chose d’universel et de définitif qui ne correspond pas (encore ?) tout à fait à la réalité.
Enfin, de même que FRBRoo est une extension du CIDOC CRM, PRESSoo est une extension de FRBRoo (ce qui le rend encore plus dur à lire que FRBRoo), mais ça, ça apparaît clairement sur votre schéma. PRESSoo n’a pas encore été validé ni par l’IFLA ni par le « CRM SIG » (le « special interest group » qui assure la maintenance du CIDOC CRM) ; c’est la raison pour laquelle la version qui a été rendue disponible sur le Web s’intitule « version 0.1 ». La future (j’espère) version 1.0 sera celle qui aura été dûment validée. Dans l’idéal il faudrait que PRESSoo disparaisse et soit purement et simplement intégré à FRBRoo, mais pour l’instant on se heurte à la difficulté politique et diplomatique de l’articulation entre FRBRer et FRBRoo : FRBRoo est censé refléter fidèlement la conceptualisation exprimée autrement dans les trois modèles FRBR, FRAD et FRSAD, sans ajout d’aucune sorte ; or, la conceptualisation exprimée dans PRESSoo s’éloigne un peu de ces trois modèles (pour la simple et bonne raison que les auteurs du modèle FRBR d’origine reconnaissaient eux-mêmes, dans le « FRBR Final Report », que la notion de « sérialité » n’avait pas été complètement explorée dans le modèle et qu’il restait du boulot). PRESSoo se présente donc véritablement comme un complément conceptuel du FRBR Final Report, et si on l’intègre à FRBRoo on ne pourra plus respecter le « deal » qui prévaut actuellement et qui veut que FRBRoo ne dise rien de plus que ce que disent déjà FRBRer & C°.
La principale différence entre FRBRer et PRESSoo, c’est que pour FRBRer les différentes versions locales d’un périodique sont considérées comme des « expressions » d’un périodique vu comme une oeuvre, alors que dans PRESSoo chaque version locale est modélisée comme une oeuvre en relation avec d’autres oeuvres. Tous les spécialistes du catalogage des périodiques avaient souligné le fait qu’il était problématique de considérer une version locale comme une « expression » d’une oeuvre, et que la modélisation des publications en série selon FRBRer n’était pas satisfaisante (il y avait des tas d’exemples où ça « coinçait »). Le problème, aujourd’hui, c’est que RDA est construit en suivant très étroitement le modèle FRBR, et que ça va forcément poser des problèmes pour la description des périodiques. C’est la raison pour laquelle le Centre international ISSN tenait à ce que ce travail de modélisation se fasse aussi rapidement que possible.
Pour terminer cet interminable commentaire, j’ajouterai qu’il reste encore du boulot sur FRBRoo : pour le moment la manière dont les photographies sont censées être modélisées selon FRBRoo est encore très floue (ce qui est tout de même dommage pour des photographies) et j’espère qu’on va pouvoir se pencher sur la question dans le courant de l’année. Et nous venons juste de recevoir des suggestions de la part du projet ECLAP pour améliorer la modélisation des spectacles…
@Patrick Le Boeuf :
un très grand merci pour ce long commentaire et toutes ces précisions.
Désolé pour mes à-peu-près : dans ma manière de présenter les choses, je me suis concentré sur ce qui m’intéressait, à savoir
1. mais d’où sort ce « FRBRoo » et comment il existe par rapport à FRBR ?
2. mais d’où sort ce « PRESSoo » ?
sans me préoccuper du fait que FRBR continuait d’exister, ainsi que le modèle CIDOC-CRM (que je n’ai pas du tout exploré, je l’avoue).
D’où aussi mon expression sur la « fusion » des groupes de travail : je voulais juste dire que ceux qui ont inventé FRBRoo venaient d’une part du groupe IFLA FRBR, d’autre part du CIDOC-CRM, sans préciser qu’ils avaient leurs activités indépendantes aussi.
Pour FRBRer : effectivement, mieux vaut préciser que le « FRBR » continue d’être légitimement employé pour désigner le modèle initial. Cela dit quand on va sur l’Open Metadata Registry, on trouve un modèle FRBRer à côté des « éléments FRBR pour RDA », ce qui est un peu perturbant.
Le fait d’avoir défini FRBRoo comme une extension du CIDOC-CRM au lieu d’en avoir fait un modèle à part, c’était par souci pragmatique (ne pas tout redéfinir) ?
Du coup, est-ce que le schéma suivant vous semble plus satisfaisant pour rendre compte de la situation ?
(il est déjà un peu plus complexe, je ne sais pas si y intégrer davantage de nuances est envisageable ! 🙂 )
Bonjour,
La nouvelle version du schéma me paraît tout à fait claire.
Le choix de définir FRBRoo comme une extension du CIDOC CRM permettait en effet de bénéficier d’une structure de base qui était plus rigoureuse et plus détaillée que celle de FRBRer, et de se rapprocher d’un formalisme adapté au Web sémantique (on ne parlait pas encore de Données liées à l’époque). Surtout, cela permettait de transformer FRBRer en un modèle « centré événement » (event-centred) permettant de mieux gérer les notions de date et d’évolution au cours du temps.
Bien cordialement, et encore bravo pour votre billet !