iln2td3 : un nouveau web service pour le suivi des propositions Rameau

Lors de la Journée des correspondants Autorités du 2 octobre dernier,  le besoin d’un outil dédié pour faciliter le suivi souvent fastidieux des Propositions Rameau avait été exprimé. C’est chose faite grâce au dernier né des webservices proposés par l’ABES. Nom de code :  « iln2td3″.
Si ce webservice a bien entendu pour objectif premier de faciliter le traitement et le suivi des Propositions Rameau par les correspondants Autorité, il entre également dans le cercle vertueux des Chantiers Qualité orchestrés par l’ABES.
Comment ça marche ?
Simple d’utilisation, le webservice s’enclenche en saisissant dans son navigateur l’URL :  http://www.idref.fr/services/iln2td3/X  –  dont on remplacera  le X situé à la fin par le numéro de son ILN, comme par exemple, pour l’ILN 15 (DDoc Bordeaux) : http://www.idref.fr/services/iln2td3/15
 A partir de cette requête, le webservice récupère dans la base Sudoc la liste des notices ayant le statut « Td3″ (= Propositions Rameau) et génère un fichier tabulé qui s’ouvre – et peut s’enregistrer – sur le poste de travail. Ce fichier comporte 6 colonnes  :
  1. PPN des notices Td3
  2. ILN concerné (iLN 15 dans cet exemple)
  3. RCR créateur de la Proposition
  4. Date de création de la Proposition
  5. Zone 250
  6. Zone 830
 Quelques exemples de suivi que devrait faciliter ce webservice  :
  • s’assurer que les Propositions RAMEAU sont pertinentes ;

  • saisir les Propositions dans le FNPR avec le numéro PPN des notices Td3 créées ;

  • en cas de refus du CNR : alerter le catalogueur à l’origine de la Proposition ;  supprimer la notice Td3 et procéder à la ré-indexation de l’ouvrage.

Vos retours d’usage sont bienvenus en commentaire.  Mais avant cela… « Bonnes fêtes à tous !!! »

CheckSUDOC, un nouvel outil de contrôle qualité des notices du SUDOC

CheckSUDOC est une nouvelle application en ligne développé en PHP  permettant d’effectuer un contrôle qualité sur les notices du SUDOC. Ce contrôle peut être effectué chaque jour une fois vos notices bibliographiques importées dans votre SIGB local.

Le fonctionnement est simple. Il s’agit de saisir une liste de PPN (identifiants des notices du SUDOC), un par ligne, et de lancer le traitement. Il existe deux modes d’affichage des résultats : simple et avancé.

Formulaire de Check Sudoc

Formulaire de Check Sudoc

Quelles vérifications sont effectuées sur chaque notice ?

 CheckSUDOC  :

  • contrôle la cohérence des années de publication saisies dans les   zones Unimarc  100  et 210 (sous-champ $d)
  • vérifie si une zone 410 (« appartient à la collection ») est présente à partir du moment où une zone 225 (« collection ») existe dans la notice
  • vérifie également la cohérence entre les champs 181-182  (« type de contenu et type de médiation ») et le sous-champ 200$b (« Indication générale du type de document »). CheckSUDOC indique si un 200$b est présent dans la notice alors que avez saisi des zones 181 et 182. En effet, à partir du 4 novembre 2014, les zones 181 et 182 se substituent à la sous-zone 200$b.
  • contrôle les vedettes matière (zones 601,602,604,605,606,607,608) ainsi que les mentions de responsabilité ( zones 700,701,702). Il vérifie en particulier la présence de liens vers les notices d’autorité qui se trouvent dans le sous-champ $3. Pour les auteurs, CheckSUDOC vérifie si le code fonction est présent ou pas.

Comment exploiter le rapport d’erreur envoyé par CheckSUDOC ?

En mode avancé, les résultats sont affichés dans un tableau dans lequel les anomalies sont signalées en rouge.

Visualisation des anomalies détectées

Visualisation des anomalies détectées

 

A partir du tableau, il est possible de visualiser la notice bibliographique dans un format abrégé en cliquant sur le numéro de PPN.  Pour chacune des zones Unimarc, il est possible d’en afficher le contenu.

Visualisation d'une zone 606

Visualisation d’une zone 606

 

En mode simple, les résultats sont présentés textuellement  sans possibilité de rebonds. Les anomalies  sont signalées en rouge.

Présentation des anomalies en "mode simple"

Présentation des anomalies en « mode simple »

En mode simple comme avancé, les résultats peuvent être téléchargés dans un fichier csv pour être exploités dans un tableur.

Plus de fonctionnalités … ?

ChekSUDOC est un outil évolutif. D’autres contrôles pourront être ajoutés sur la base de vos suggestions.

Pour utiliser CheckSUDOC : http://domybiblio.net/check_sudoc/

 

CheckSUDOC est développé par Yves Tomic, Ingénieur d’études à l’Université Paris Dauphine.

 

 

 

Un chantier qualité sur les n° FRBNF multiples

Dans un catalogue de bibliothèque, quel qu’il soit, chaque notice dispose de son propre identifiant. Dans le Sudoc, c’est un numéro appelé « PPN ». Il identifie les notices bibliographiques et les notices d’autorités.

Ces dernières, dans l’environnement BnF, disposent de leurs propres identifiants : les numéros FRBNF, visibles en zone 001 des notices BnF.

Lorsqu’un catalogueur Sudoc ne trouve pas une notice pour le point d’accès qu’il veut normaliser, il a l’opportunité de chercher si une notice pour cette autorité existe dans la base d’appui (=DIS CHE de WinIBW) où l’on trouve les notices d’autorité de la BNF, laquelle nous les offre gracieusement depuis l’origine du Sudoc.

Sinon, il devra la créer nativement dans le Sudoc.

Dans le cas où il la trouve dans la base d’appui, la commande F5 lui permet de dériver la notice : celle-ci se voit alors dotée d’un PPN et l’identifiant FRBNF passe de la 001 notice BNF à la 035 notice Sudoc. Au moment de dériver, la question de conserver ou pas le numéro FRBNF se pose.

Faut-il conserver le n° FRBNF ?

Cas n° 1 : S’il s’agit de décrire la même personne, la même entité, le même concept dans l’environnement « Sudoc » que dans l’environnement « BnF », il est logique de le conserver. En conservant ce numéro, on indique à tout système qui viendrait « lire » la notice Sudoc : « cette notice a une jumelle dans l’environnement BnF, c’est ce n° FRBNF qui te permettra au besoin de l’identifier et de reconstituer la paire« .

Cas n° 1

Cas n° 1 : dériver pour décrire une même personne

Cas n° 2 : S’il s’agit de dériver la notice BnF pour s’en servir, dans l’environnement Sudoc, comme d’un modèle pour la création d’une personne, d’une entité, d’un concept qui, au final, sera différent, il est logique de ne pas conserver ce n° FRBNF. Après sa validation dans le Sudoc, la notice d’autorité produite s’avèrera différente de celle qui, par commodité, aura servie de modèle. Elles ne sont pas jumelles, il n’y aura jamais lieu de les apparier.

Cas n° 2

Cas n° 2 : dériver un modèle pour décrire une autre personne

Il arrive cependant que des catalogueurs, dans cas n° 2, négligent de supprimer la zone 035 de la notice utilisée comme modèle. Et après validation, il est délicat de revenir en arrière (seuls les logins de type TA disposent désormais de cette habilitation). La notice d’autorité Sudoc hérite alors d’un numéro identifiant BnF  :

  • qui n’a rien à voir avec l’entité qu’elle décrit,
  • qui peut se trouver ailleurs, dans une autre notice d’autorité Sudoc  créée dans le cas n° 1 où sa présence est justifié.

On se retrouve alors en présence de notices qui ne sont pas des doublons (elles décrivent bien des entités différentes) mais qui, pour être distinctes l’une de l’autre, conservent néanmoins un n° FRBNF identique. Ce sont des « doublons de FRBNF ».

2 notices distinctes avec un FRBNF commun

2 notices distinctes avec un FRBNF commun

Combien de notices étaient dans ce cas ?

En septembre 2014, l’ABES en a dénombré quelques centaines (auxquelles il convient d’ajouter des « vraies » notices doublons, créées par copies intempestives ou suite à une recherche négligée).  Pourtant, en décembre 2013, l’ABES avait déjà procédé à un nettoyage. Ces centaines de « doublons FRBNF » avaient été créés au cours des 8 derniers mois !  Il y avait une certaine urgence à alerter le réseau, pour éviter l’hémorragie et pour sensibiliser à la question des identifiants.

Une prise de conscience sur l’importance des identifiants.

La question des identifiants (PPN, FRBNF, etc.) est de plus en plus présente dans les priorités de l’ABES car ils interviennent dans les alignements de « nos » données avec celles d’autres catalogues, à commencer par nos applications STAR, STEP ou Calames et plus loin BNF, VIAF, ISNI. En effet, les identifiants contenus dans les notices sont bien souvent l’unique clé permettant à une application extérieure de venir retrouver les informations des autorités du Sudoc.

En octobre 2014, 74 correspondants Autorités d’établissements identifiés comme ayant créé une ou plusieurs notices d’autorité « avec FRBNF multiples » ont été invités à rectifier ces anomalies, à l’aide d’un fichier listant les n° PPN des notices concernées et de consignes de résolution :

  • s’il s’agit d’un vrai doublon : signalement sur le guichet ABESstp pour traitement par l’ABES
  • s’il s’agit d’une notice avec un FRBNF qui n’a pas lieu d’être présent : suppression de l’intrus en zone 035

Un réseau très réactif !

Il faut ici saluer la promptitude, voire l’enthousiasme avec lesquels les établissements concernés se sont empressés de répondre à notre invitation. Seulement 3 jours après le lancement du chantier, déjà 33 % des notices concernées avaient été vérifiées. Cet élan a été freiné par l’impossibilité technique de supprimer la zone 035 pour les détenteurs d’un login de type TA (groupe des « tcatalogueurs », soit les correspondants Autorités). Elle a été levée, en élargissant les habilitations liées à ce login, et le travail a pu alors reprendre.

Pour ce chantier, le risque ne résidait pas dans le nombre de notices à traiter, mais dans le mode de traitement. Contrairement aux précédents chantiers qualités (voir ici et ), le travail de correction ne reposait pas uniquement sur l’ABES : le réseau devait participer. Il a répondu présent ! Cette réactivité atteste non seulement de l’intérêt des correspondants Autorités et de leurs équipes pour les questions liées à la qualité des données, mais plus globalement de la vitalité du réseau, ainsi que de sa modernité. L’enjeu majeur de ce chantier a bien été perçu : il s’agit de ne plus concevoir nos données dans un contexte isolé, mais comme appartenant à un écosystème où elles vivent, s’échangent et interagissent.

Un chantier « qualité » sur les données d’autorités

C’est un chantier modeste par le volume des notices concernées, mais important par ses impacts, que nous mettons ici en lumière.

Dans les notices d’autorités de la base Sudoc, les zones Unimarc 5XX permettent de faire des liens vers d’autres notices (lien de type « Voir aussi »). Sur un affichage public, cela se matérialise ainsi :

Notice d'autorité avec zones 5XX

Le bloc 5XX du format Unimarc Autorités prévoit 8 étiquettes différentes, chacune devant contenir un lien vers une notice d’autorité spécifique : l’étiquette 500 doit pointer  vers une notice d’autorité « Personne physique » (Tp), l’étiquette 510 vers une notice d’autorité « Collectivité » (Td), l’étiquette 515 vers une notice d’autorité « Nom géographique » (Tg), etc.

Le chantier a donc consisté dans un premier temps à vérifier ces liens, dans un second temps à rectifier l’étiquette lorsqu’elle avait été utilisée à mauvais escient.

Par exemple, dans toutes les notices où un lien en 550 pointait vers une notice autre qu’une « Autorité nom commun » (Td), il a fallu intervenir pour rétablir un catalogage conforme aux préconisations de l’Unimarc A (dans la notice liante et parfois dans la notice liée).

De tels liens erronés peuvent avoir de multiples sources : erreur de catalogage, mais aussi non répercussion de mises à jour effectuées par la BnF dans son catalogue sous la forme d’un changement de typage dans l’autorité liée.

Un exemple concret :

L’autorité Td Symbolisme dans la Bible est devenue Tu Bible — Symbolisme.

Pour des raisons techniques, la notice liée Td Lumières et ténèbres dans la Bible, mise à jour côté BnF, n’a pas été refournie au Sudoc qui a conservé une étiquette de lien 550 vers Bible — Symbolisme, alors qu’une étiquette 530 s’imposait désormais.

Il en a résulté un défaut d’affichage dans le Sudoc d’une part ; des anomalies dans les exports, bloquantes pour certains SIGB, d’autre part.

Ce chantier a concerné quelques centaines de notices d’autorité.

À l’échelle du catalogue Sudoc, c’est heureusement peu.

Il fallait pourtant le faire, pour la raison évoquée ci-dessus et au moins pour 3 autres, au-delà de l’intérêt pour le travail bien fait :

  1. les notices d’autorités jouissent désormais d’une grande visibilité, via l’application web IdRef  : elles doivent être impeccables ;
  2. elles sont alignées avec d’autres référentiels nationaux ou internationaux : nous nous devons d’exposer des données fiables ;
  3. elles sont exportables vers d’autres applications, dans d’autres formats, dont l’ABES ne pourrait contrôler l’affichage, s’il s’avérait erroné.

 

Un chantier « qualité » sur le 200$b

Avant (mars 2014), dans le Sudoc,  8 700 000 notices avaient une sous-zone 200 $b.

Sauf que celle-ci, qu’un catalogueur peut saisir à la main (même si, rappelons-le, un script « Ajout Texte imprimé » est disponible), contenait des valeurs très … différentes et hétéroclites.

Quelques exemples d’occurrences trouvées, pour la seule valeur « Texte imprimé » :

  • texte imprimé (dans 48.116 notices)
  • Texte imprimée (dans 1.051 notices)
  • TEXTE IMPRIME (dans 785 notices)
  • Texte imprimét (dans 515 notices)
  • Texte imrimé (dans 477 notices)
  • Texte imprimé. (dans 230 notices)
  • Texteimprimé (dans 136 notices)
  • Texte impriméé (dans 28 notices)
  • Etc.

Quelques exemples d’occurrences trouvées, pour la seule valeur « Document cartographique » :

  • Document cartographiquee (dans 6 notices)
  • Document cartographiques (dans 6 notices)
  • Documents cartographiques (dans 6 notices)
  • Document cartograpgique (dans  4 notices)
  •  Document carthographique (dans  4 notices)
  •  bDocument cartographique (dans  4 notices)
  •  Document cartopographique (dans  4 notices)
  •  documents cartographiques (dans  4 notices)
  • Etc.

D’autres valeurs ont été trouvées, telles que :

  • Images animées] : Préparation aux agrégations d’EPS et à la maîtrise STAPS  » Education et motricité
  • Texte impriméA documentary history of Tibet’s international status, the great rebellion and its aftermath

… dans des notices où l’oubli de saisie du « $ » de la sous-zone suivante enregistrait la chaine de caractères entière comme une « valeur » du 200$b !

Au total, près de 8400 valeurs incorrectes différentes de 200 $b ont été trouvées, pour plus de 126 000 notices bibliographiques.

Les multiples valeurs du 200$b

Les multiples valeurs du 200$b (image par Teillas, CC-BY-NC-ND via Flickr)

Aujourd’hui, après recensement et corrections de masse : 9 086 557 notices ont une sous-zone 200 $b.

Elles se répartissent ainsi :

Valeur Nombre d’occurrences
Texte imprimé 7760910
Ressource électronique 764481
Enregistrement sonore 180184
Images animées 152571
Document cartographique 68521
Microforme 65488
Musique imprimée 44882
Multimédia multisupport 37878
Image fixe 9849
Texte manuscrit 1388
Musique manuscrite 287
Braille 71
Objet 54
Document cartographique manuscrit 3

La table de validation du Sudoc contrôle désormais qu’aucune autre valeur ne peut être saisie.

Ce chantier « qualité » permettra d’appréhender sereinement les modifications de masse à envisager lorsque les zones Unimarc 181 et 182 apparaîtront, qui conduiront à la suppression définitive de ce 200$b.

Le SUDOC en RDF : du nouveau ! 2/2

RDA en RDF : pourquoi, comment ?

Fidèles au principe de réutiliser au maximum des vocabulaires déjà publiés, et si possible « métiers », c’est assez naturellement du côté de RDA, qu’on a cherché la sémantique adéquate. On utilisait déjà des propriétés et des classes telles que : ModeOfIssuance, WorkManifested/ManifestationOfWork, et la classe Work.

 Pour les zones de liens, ce vocabulaire est celui qui, en général, « colle » le mieux avec les données issues de l’Unimarc.

Il y avait toutefois un problème avec RDA en RDF : il était publié depuis 2009 à l’état de « propositions » seulement (« new-proposed », sur Open Metadata Registry), donc de brouillon.  Or, le JSC (Joint Steering Commitee, en charge du développement et de la diffusion du code de catalogage  RDA), s’est penché récemment sur son sort et a décidé d’en publier une nouvelle version consolidée et validée, sur l’OMR. L’espace de nom a été changé : l’URL http://www.rdaregistry.info/ accueille désormais l’ensemble des classes et propriétés RDA, ainsi que l’ensemble de la documentation associée.

Cette validation est en elle-même très positive, car elle donne une certaine garantie sur la pérennité et le maintien de ce vocabulaire. Mais dans l’immédiat, le changement d’espace de nom rend obsolètes les propriétés et classes précédemment utilisées, obligeant à une mise à jour du modèle de données. Il ne faudrait donc pas que cela devienne une habitude… D’autant plus que les listes de vocabulaires contrôlés (listes fermées de valeurs) sont restées sur l’ancien espace de nom http://rdvocab.info/. Ce qui ne simplifie pas les choses.

Les propriétés sont désormais, comme pour l’ISBD, identifiées par des codes opaques, et non plus par des libellés en anglais. Ce qui peut aussi se discuter car ne facilite pas leur manipulation. Mais elles sont désormais officiellement utilisables.

Ce vocabulaire comporte plusieurs sous-domaines : les agents (rdaa), les classes (rdac), et les propriétés, réparties selon leur domaine d’application FRBR : rdaw : pour les propriétés d’œuvres ; rdae, pour celles des expressions ; rdam, pour les manifestations, rdai, pour les items.

La plupart des catalogues, SUDOC compris, n’étant pas, ou très imparfaitement, FRBRisés, un domaine « unconstrained properties » (rdau), rassemble également l’ensemble des propriétés précédentes. C’est celui qui a été retenu pour les zones de liens.

Exemple

Une zone 430 (Suite de) exprime en principe une relation entre deux œuvres. Mais la ressource décrite dans le Sudoc est plutôt une manifestation. C’est pourquoi seul l’usage d’une propriété sans contrainte de domaine  est correct. En l’occurrence : « is continuation of » dont l’état civil sur le web de données est rdau:P60576.

M. Jeulin

De F. Rieder. CC BY-NC-SA 2.0. Source : Flickr

De F. Rieder. CC BY-NC-SA 2.0. Source : Flickr

Le SUDOC en RDF : du nouveau ! 1/2

A propos du  web de données, et du Sudoc en RDF, voir notamment les billets précédents ici et .

L’été 2013 avait vu la mise en ligne d’une documentation sur l’exposition du SUDOC en RDF, et l’annonce d’un chantier visant à enrichir et affiner progressivement celle-ci. Ce chantier a produit ses premiers résultats au cours de l’année universitaire écoulée, par petites touches successives. Zoom sur les nouveautés.

Alignements

Dans un souci d’interopérabilité avec Data.bnf.fr, le FRBNF des notices BNF a été ajouté, à côté des OCN d’OCLC déjà présents : onto-bnf :FRBNF (propriété maintenue par la BnF elle-même). Les identifiants ark – présents dans une partie des notices du Sudoc, devraient suivre un peu plus tard.

Types de documents

Pour typer les documents décrits, on fait appel, de façon partiellement redondante, à trois vocabulaires :

-  Bibliographic ontology (plus familièrement « bibo »). C’est un vocabulaire simplifié d’usage assez large, au-delà de la communauté professionnelle des bibliothécaires

- Dublin Core, encore plus générique

- ISBD en RDF, maintenu par l’IFLA. Celui-là correspond plus strictement à nos standards de description bibliographique. Plus précis mais sans doute plus déroutant pour le profane…

Jusqu’ici, on utilisait de « bibo » que les classes « Book », « Periodical », « Series ». D’autres types de documents sont désormais identifiés: « Image », « Audio », « Audiovisual »…

- Idem pour Dublin Core : Image, Moving Image, Sound…

Côté ISBD, on utilise les deux propriétés isbd:P1001 « Content form » (type de contenu) et isbd:P1003 « Media type » (type de « médiation ») qui font appel à des listes de valeurs contrôlées.

Auparavant on ne distinguait guère que les documents imprimés et électroniques.  Désormais, le spectre des documents identifiés est plus large, même si pas encore tout à fait exhaustif : images fixes ou animées, documents musicaux ou sonores, cartographiques, microformes…

Exemple (RDF/XML):

<bibo:AudioVisualDocument rdf:about="http://www.sudoc.fr/114415641/id">
 <dc:title>Les Shadoks  [Images animées]  : l'intégrale des origines à nos jours  / René Borg, Robert Richez, Jacques Rouxel... [et al.], réal.  ; Jacques Rouxel, texte  ; Robert Cohen-Solal, comp.  ; Claude Piéplu, voix</dc:title>
 …
 <isbd:P1001>
 <skos:Concept rdf:about="http://iflastandards.info/ns/isbd/terms/contentform/T1002">
 <skos:prefLabel xml:lang="en">image</skos:prefLabel></skos:Concept>
 </isbd:P1001>
 <isbd:P1003>
 <skos:Concept rdf:about="http://iflastandards.info/ns/isbd/terms/mediatype/T1007"><skos:prefLabel xml:lang="en">video</skos:prefLabel></skos:Concept>
 </isbd:P1003>
 …
 </bibo:AudioVisualDocument>

Soit en Turtle :

<http://www.sudoc.fr/114415641/id> a bibo:AudioVisualDocument ;
 dc:title "Les Shadoks  [Images animées]  : l'intégrale des origines à nos jours  / René Borg, Robert Richez, Jacques Rouxel... [et al.], réal.  ; Jacques Rouxel, texte  ; Robert Cohen-Solal, comp.  ; Claude Piéplu, voix" ;
 isbd:P1001 <http://iflastandards.info/ns/isbd/terms/contentform/T1002> ;
 isbd:P1003 <http://iflastandards.info/ns/isbd/terms/mediatype/T1007> ;
 dc:type "Moving Image" ;
  
 <http://iflastandards.info/ns/isbd/terms/contentform/T1002> a skos:Concept ;
 skos:prefLabel "image"@en .
 <http://iflastandards.info/ns/isbd/terms/mediatype/T1007> a skos:Concept ;
 skos:prefLabel "video"@en .

Zones de liens bibliographiques : Unimarc 4XX

Ces liens se trouvent dans les zones 4XX de l’Unimarc, une bonne partie d’entre eux concernant les périodiques dont ils permettent de reconstituer l’historique (suite de/ devient, fusions/scissions, etc.).

Jusqu’ici, seule une petite partie d’entre eux était convertie, à l’aide des propriétés relationnelles de Dublin Core, beaucoup moins précis en la matière que l’Unimarc : hasFormat, relation, hasVersion.

A présent presque tous ces liens sont publiés. Il reste encore un peu de  Dublin Core (is part of / has part), de Bibo, à la marge (notamment pour les tirés à part) ; le reste avec RDA qui a fourni l’essentiel du vocabulaire ad hoc. (Voir la suite)

Certaines relations ont été par la même occasion précisées par une nouvelle propriété : par exemple « Est une reproduction de » : traduit par dcterms:isFormat l’est désormais par rdau:P60297 (is reproduction of)

Deux zones Unimarc sont encore exprimées de façon approximative :

- 451 : Autre édition sur un même support

- 452 : Autre édition sur un support différent

Elles n’existent dans aucun vocabulaire et devront être forgées.

La suite consistera à exposer  ces mêmes champs 4XX quand ils n’ont pas de lien, c’est-à-dire lorsqu’ils sont utilisés comme points d’accès. Comme, par exemple, les nombreuses 463$t ou 464$t (Comprend) contenant des titres de volumes ou d’œuvres contenues.

Mises à jour, présentes et à venir : bonnes pratiques

L’ancienne propriété a été pour l’instant  conservée, de façon redondante.

Par ailleurs, les propriétés RDA WorkManifested, ManifestationOfWork, et la classe Work : déjà utilisées dans quelques cas précis (titres uniformes, thèses) sont désormais obsolètes et sont  remplacées par leurs homologues rdam:P30135, rdac:C10001. De même que modeOfIssuance par  rdau:30003

A noter que le vocabulaire obsolète est pour l’instant maintenu. Ceci dans un souci d’assurer une interopérabilité entre deux versions du modèle de données, et d’éviter de « casser » des applications qui exploiteraient les données impactées. Ce principe ne pourra pas toujours être appliqué, mais à l’avenir, les modifications apportées à l’existant seront annoncées à l’avance avec une échéance, comme pour les modifications habituelles de format.

A ce propos, tous les retours sont les bienvenus !

Chantier ouvert au public, casque obligatoire

D’après A. Raanes. CC by 2.0. Source :Flickr

Rappelons enfin que tout ce qui précède est détaillé dans la documentation en ligne :

http://documentation.abes.fr/sudoc/manuels/administration/sudoc_rdf

M. Jeulin