Dans le dernier Dlib, on peut lire un article très intéressant de Karen Coyle, Diane Hillmann, Jon Phipps et Gordon Dunsire sur l’expression de RDA en RDF. Il rend compte d’un travail effectué dans le cadre du groupe de travail DCMI/RDA qui comme son nom l’indique travaille sur le rapprochement entre Dublin Core et RDA.

Pour mémoire, les RDA (Resource Description and Access) sont un ensemble de nouvelles règles de catalogage en cours d’élaboration dans la communauté anglo-saxonne, dont le principal caractère novateur est de prendre acte de la modélisation définie par les FRBR.

En fait ce qu’ils présentent dans l’article c’est un premier travail pour exprimer les RDA sous la forme d’une ontologie en RDF, qui est disponible en ligne dans le répertoire de métadonnées de la NSDL.

L’article rappelle qu’il s’agit d’un premier travail, qui arrive en avance de phase par rapport à la version définitive de RDA (prévue en juin). Pourtant, ils ont apparemment couvert sinon tout, du moins une grande partie des concepts et des éléments de description prévus.
Ce qui leur a posé plusieurs problèmes…

Le premier étant l’alignement avec les FRBR. Ils ont redéclaré des principales classes des FRBRer en attendant qu’une ontologie digne de ce nom soit publiée par l’IFLA. Mais les FRBRer n’étant pas tout à fait prévus pour cela, ils ont rencontré différents problèmes :
– ils ont dû utiliser une classe des FRBRoo, la classe Agent, sans quoi ça ne tenait pas la route (!)
– pour pas mal d’éléments RDA, le rattachement aux entités FRBR peut être discuté et on ne peut pas rattacher de façon univoque une propriété des RDA à une seule entité FRBR. Pour pallier ce problème ils ont déclaré les propriétés concernées deux fois, une fois de façon générique, puis une deuxième fois sous la forme d’une sous-propriété rattachée à l’entité FRBR choisie.

Le passage en RDF a l’avantage de mettre un certain nombre de relations en évidence de façon explicite.
Mais il implique aussi des contraintes : notamment le fait de mettre les propriétés sur un seul niveau (et pas imbriqué comme en MARC ou en XML).
Le traitement de certains trucs très spécifiques aux pratiques des bibliothèques, comme les mentions déclaratives (la mention d’édition par exemple, sous la forme « Éditeur : lieu, date ») est d’une complexité abominable dès lors qu’on veut les décomposer en plusieurs sous-parties dont certaines peuvent être des ressources (identifiées par des URI, pour les lieux par exemple) et pas seulement des littéraux (des chaînes de caractères).

L’article contient aussi un argumentaire assez intéressant sur l’utilisation d’un « metadata registry » pour déclarer les entités de RDA.
Le répertoire de métadonnées de la NSDL leur permet ainsi de diffuser à la fois une version lisible pour les humains (en HTML, sous forme de tableaux) et une version pour les machines (en RDF avec des URI). Il permet aussi de gérer le versionning et des mécanismes d’alertes.

L’article conclut enfin en soulignant les principaux avantages de cette démarche visant à modéliser les données des catalogues de bibliothèque pour le Web sémantique : il s’agit de permettre à d’autres acteurs d’appréhender ces donnés de façon plus simple qu’avec les formats MARC (cf. les propos de Google à l’ALA forum) mais aussi de nous aider à tirer le bénéfice de données créées par d’autres, comme DBPedia. Il se termine enfin avec une ouverture aux autres communautés proches des bibliothèques : institutions patrimoniales, éditeurs, etc.

Voilà pour l’article. Du côté du modèle lui-même, on va donc trouver trois choses :
– les classes correspondant aux entités FRBRer (+FRBRoo:Agent)
– les propriétés correspondants aux éléments des RDA
– les concepts conrrespondant aux listes de vocabulaires, à utiliser avec les propriétés.

Après une première et très courte analyse, ce RDA en RDF me semble une initiative assez prometteuse avec laquelle on va pouvoir commencer à s’amuser un peu… Même s’il y a sans doute encore des évolutions à prévoir.
Par exemple, on peut s’étonner de certains choix de modélisation comme le fait d’utiliser systématiquement SKOS:concept pour les vocabulaires. Autre truc bizarre, les vocabulaires sont faits pour être utilisés avec les propriétés mais l’ontologie ne le précise pas formellement ; il faut donc se débrouiller tout seul pour comprendre, par exemple, que la liste de concepts « RDA carrier type » doit être utilisée avec la propriété RDA:carrierType (là ça peut paraître évident, mais ce n’est pas toujours aussi simple malheureusement).

Bref, l’ensemble donne parfois l’impression d’avoir été conçu davantage comme un modèle de données traditionnel que comme une ontologie pour le Web sémantique, et qu’il n’en utilise pas toute l’ingénierie, ou pas correctement.
J’espère que les gens qui en savent plus que moi sur la modélisation d’ontologie n’hésiteront pas à s’exprimer sur le sujet ;-)