Pour des besoins de gestion interne, spécifiques à un établissement ou encore dans le projet d'initier un nouveau format de métadonnées pour échanger avec un certain nombre de partenaires, on souhaite parfois ajouter ou modifier profondément les possibilités données par le formulaire OAI_DC.
Ce cas peut se présenter pour la gestion des documents "administratifs" par exemple, pour contrôler plus finement les choix possibles d'un champ donné (dc:type par exemple), etc.
dc:type - liste de sélections
But: ne proposer qu'un vocabulaire fermé pour dc:type.
modifications dans l'éditeur
- Dans le fichier WEB-INF/resources/forms/ori-md-editor/oaidc-full/form/form.xhtml
Déclaration d'un nouveau vocabulaire adminTypes :
<xforms:instance id="adminTypes" src="/fr/service/custom/ori-md-editor/oriGetVocab?vocab=admin_types" xxforms:readonly="true" xxforms:shared="application"/>
Le control XForms de dc:type n'est plus un xforms:input mais un xforms:select1
<widget:ori-block element="dc:type" minOccurs="0" maxOccurs="unbounded"
preceding-elements="dc:date | dc:contributor | dc:publisher | dc:description | dc:subject | dc:creator | dc:title">
<xforms:select1 ref=".">
<xforms:label class="hidden">xforms:output value="$fr-resources/ori-oaidc-type" /></xforms:label>
<xforms:alert><xforms:output value="$fr-resources/ori-alert" /></xforms:alert>
<xforms:item>
<xforms:label>[Select]</xforms:label>
<xforms:value/>
</xforms:item>
<xforms:itemset nodeset="xxforms:instance('adminTypes')/vdex:term">
<xforms:label ref="vdex:caption/vdex:langstring"/>
<xforms:value ref="vdex:termIdentifier"/>
</xforms:itemset>
</xforms:select1>
</widget:ori-block>
- Pour un usage en local/standalone, on ajoute dans WEB-INF/resources/forms/ori-md-editor/common/xml-vocab-local un vocabulaire admin_types.xml
vocabulary
Pour l'usage en utilisant le module ori-oai-vocabulary, on ajoute ce admin_types.xml dans conf/properties/ori_vocabularies/override
search
Pour prise en compte de ce nouveau vocabulary dans le moteur de recherche / recherche avancée :
Si on utilise un config.xml type documentaire, on modifiera properties/advanced/documentaire/advanced_distants.xml pour y ajouter :
<field format="text" id="doc_format" vocabularyId="admin_types" type="select:5"> <metadata>//dc:type</metadata> </field>
extension DC / OAI_DC
On peut avoir envie d'étendre le formulaire OAI_DC, c'est à dire d'ajouter des possibilités non présents par défaut : nouveaux champs etc.
Comme pour l'extension d'autres formulaires (et donc de schémas de métadonnées) cela n'est pas annodin. En effet en étendant ces schémas, on ne va plus correspondre strictement à un schéma XML standardisé donné, mais on aura quelque chose de spécifique à notre établissement qui sera donc potentiellement difficile à échanger/partager avec d'autres.
Procéder à ce type de manipulations peut toutefois s'avérer nécessaire lorsqu'on souhaite mettre en place des métadonnées/champs effectivement très spécifiques à son établissement (métadonnées/champs internes non dédiés à être partagés), cela peut également être un travail à effectuer lors de l'élaboration d'un nouveau type de XML qui sera échangé par plusieurs partenaires (d'une même UNR, UNT ou plus encore).
Même si l'ajout est spécifique ou découle d'un besoin exprimé par plusieurs entités, il est préférable de "se raccrocher" au mieux à des usages et standards existants. Il est en effet très rare que l'on ressente un besoin jamais exprimé par d'autres établissements (à un niveau international).
Dans le cadre de OAI_DC, l'usage des extensions DC/DCMI est relativement usuelle.
On regardera donc attentivement les éléments que peuvent proposer ces différents schémas http://dublincore.org/schemas/xmls/ pour inclure certaines métadonnées/champs dans un formulaire spécifique OAI_DC.
Voir à ce propos également le formulaire dc_plus_fr en construction dans ori-oai-md-editor