Différences

Ci-dessous, les différences entre deux révisions de la page.

--- scrutaridata:uri [2016/07/06 17:43]
vincent ↷ Nom de la page changé de scrutaridata:uuid_uri à scrutaridata:uri
+++ scrutaridata:uri [2016/07/07 13:36] (Version actuelle)
vincent
@@ Ligne 1: / Ligne 1: @@
-====== UUID et URI : identification du contenu de manière unique ======
+====== URI : identification du contenu de manière unique ======
-===== UUID =====
 L'objectif de Scrutari est de rassembler des informations provenant de sites différents. Se pose alors la question de donner une identification unique à chacun des contenus transmis par le format de ScrutariData (autrement dit les fiches, les mots-clés, les corpus, les thésaurus et les bases elles-mêmes) afin d'éviter les conflits. En interne, le serveur Scrutari attribue un numéro à chacun de ces contenus mais ce numéro n'est pas pérenne (sauf paramétrage particulier), n'est pas signifiant et reste propre au serveur lui-même alors qu'un même fichier au format ScrutariData peut être utilisé par plusieurs serveurs différents.
-Le principe adopté dans Scrutari repose sur l'UUID (//Universally Unique Identifier// : identifiant unique universel) qui est un mécanisme de génération d'identifiants assurés d'être unique. De nombreux langages de programmation possèdent une bibliothèque susceptible de générer cet identifiant et des sites proposent d'en créer un en ligne (par exemple, http://www.famkruithof.net/uuid/uuidgen).
+Le principe adopté dans Scrutari repose sur la construction d'un URI (//Unique Resource Identifier//) pour chacun de ces éléments. Tous ces éléments ont un tronc commun constitué d'un nom identifiant de l'autorité productrice de la base et du nom de la base.
-Attribuer un identifiant unique sous la forme d'un UUID à chaque contenu serait laborieux et risquerait de compliquer sérieusement la tâche. L'idée est donc de n'utiliser qu'un seul UUID, l'UUID du producteur de l'information (l'élément //<authority-uuid>// dans l'élément //<base-metadata>//), c'est ensuite ce producteur d'information qui a la responsabilité de nommer la base et les autres contenus du fichier au format ScrutariData.
+Cela donne les formes suivantes :
-Ainsi dans l'exemple suivant :
+  *URI d'une base : //base:/nom de l'autorité/nom de la base//
+  *URI d'un corpus : //corpus:/nom de l'autorité/nom de la base/nom du corpus//
+  *URI d'une fiche : //fiche:/nom de l'autorité/nom de la base/nom du corpus/identifiant de la fiche//
+  *URI d'un thésaurus : //thesaurus:/nom de l'autorité/nom de la base/nom du thésaurus//
+  *URI d'un mot-clé : //motcle:/nom de l'autorité/nom de la base/nom du thésaurus/identifiant du mot-clé//
+Nous pouvons voir que l'URI commence par un protocole qui indique la nature de l'élément. Cela permet notamment de distinguer un corpus d'un thésaurus qui auraient le même nom. Le fait que l'URI commence par le nom de l'autorité donne toute latitude à celle-ci pour les noms de base, de corpus ou de thésaurus.
+Le nom de l'autorité peut être un nom de domaine, un identifiant universel unique (UUID), voire le sigle de la structure lorsque Scrutari est utilisé en interne et qu'il n'a a pas de risque de conflit. Dans les premières versions de Scrutari, le nom de l'autorité devait être un UUID, ce qui explique que de nombreux exemples utilisent cette forme. Le nom de l'autorité doit être composé de minuscules et majuscules sans accent, de chiffres et des caractères //.-_//.
+Le nom de l'autorité et celui de la base sont déclarés dans l'élément //<base-metadata>// comme dans l'exemple suivant :
 <code xml>
 <base>
 <base-metadata>
-   <authority-uuid>e17a05b0-c45e-11d8-9669-0800200c9a66</authority-uuid>
+   <authority>e17a05b0-c45e-11d8-9669-0800200c9a66</authority>
    <base-name>gouvafrique</base-name>
    ...
@@ Ligne 24: / Ligne 32: @@
 </base>
 </code>
-Le code du corpus « analyse » est le composé de l'UUID, du nom de la base et du nom du corpus, soit : <color grey>e17a05b0-c45e-11d8-9669-0800200c9a66/gouvafrique/analyse</color>.
-Il n'y a donc pas de risque de doublons entre deux producteurs d'information qui ont des UUID différents. Par contre, un même producteur d'information doit prendre garde aux doublons s'il utilise le même UUID dans différents fichiers au format ScrutariData. Pour éviter des doublons, il suffit tout simplement de nommer les bases différemment (via l'élément //<base-name>// dans //<base-metadata>//) : <color grey>e17a05b0-c45e-11d8-9669-0800200c9a66/gouvafrique/analyse</color> et <color grey>e17a05b0-c45e-11d8-9669-0800200c9a66/gouvafrique2/analyse</color> sont bien deux corpus différents même si leur nom (//analyse//) est le même
-===== URI =====
-De l'UUID à l'URI (//Unique Resource Identifier//), il n'y a qu'un pas : comme on l'a vu avec l'exemple des corpus, l'agrégation UUID + nom de la base + nom du corpus permet de distinguer les corpus entre eux. En précédant cette agrégation d'un espace de nom, on obtient un URI.
-Cela donne les formes suivantes :
-  *URI d'une base : //base:/UUID/nom de la base//
-  *URI d'un corpus : //corpus:/UUID/nom de la base/nom du corpus//
-  *URI d'une fiche : //fiche:/UUID/nom de la base/nom du corpus/identifiant de la fiche//
-  *URI d'un thésaurus : //thesaurus:/UUID/nom de la base/nom du thésaurus//
-  *URI d'un mot-clé : //motcle:/UUID/nom de la base/nom du thésaurus/identifiant du mot-clé//
-L'URI est d'ores et déjà utilisé dans des fichiers de configuration du serveur Scrutari.
-Une des applications possibles des URI serait le partage de thésaurus entre plusieurs bases. Cette application n'est pas encore opérationnelle dans le serveur Scrutari.