Conseil n°2 : Choisir une structure d’URI adéquate

déployer en interne individuellement, les recommandations semblent systématiquement se tourner vers l’utilisation d’URI http, dont l’une des caractéristiques est de faciliter la manipulation. En effet, l’objectif intrinsèque des l’identifiants est qu’ils soient communiqués. Ils sont la plupart du temps utilisés dans ce seul but, transcendant les domaines d’activité et les catégories d’utilisateurs. Il est donc recommandé de se préparer à des cas d’utilisation larges et variés, même si au départ il ne semble pas que cela soit réellement nécessaire.404 Et si l’information n’a pas d’URL, elle n’existe pas sur le web. Le déréférencement via un navigateur est de surcroit extrêmement pratique et intuitif pour notre société immergée dans l’hypertextuel. Ce n’est évidemment pas le choix idéal pour tous les cas, notamment sur des organismes à la politique de confidentialité spécifique, qui ne souhaitent pas publier sur le web mais pouvoir lier leurs données en interne, ou utiliser les technologies pour leur intranet par exemple, etc.

Selon l’EC Informal Working Group on Persistent URIs, le groupe de travail dédié de l’ISA, les URI devraient toujours avoir une structure telle que 405_:

(racine URI : scheme+ autorité)/(chemin ou path)/(type ou provenance)/(chaine de caractère)/(options)

Les spécificités fonctionnelles de la syntaxe même d’une URI définies par Tim Berners-Lee sont du même ordre406 :

(Scheme)/(autorité)/(chemin ou path)/(requête)/(fragment)

Nous constatons que seuls la racine et le chemin de la ressource sont nécessaires à toutes les URI, même si celles-ci ne sont pas des URI http. Par exemple, certains URN rentrent également dans ce cadre bien qu’ils ne présentent pas d’autorité ni de fragment407_:

urn :(racine) exemple : animal : toucan : bec(chemin)

Le chemin peut présenter une organisation hiérarchique pour spécifier le périmètre de l’URI. C’est également un moyen de contextualiser ou d’apporter des éléments lisibles et compréhensibles pour la manipulation de la ressource, par exemple. Les options sont quant à elles des suffixes modulables permettant d’apporter différents services, elles ne comportent généralement pas de garantie de pérennité contrairement au reste de l’identifiant.

403 _{DAVIDSON, Paul, CIO Sedgemoor, District Council. Op. Cit.}

404 _{HILSE, Hans-Werner, KOTHE, Jochen. Implementing Persistent Identifiers. Consortium of European Research} Libraries, 2006. Disponible sur: http://webdoc.sub.gwdg.de/edoc/ah/2006/hilse_kothe/urn%3Anbn%3Ade%3Agbv%3A7 - isbn-90-6984-508-3-8.pdf [consulté le 12/04/2017]

405 _{ARCHER, Phil, GOEDERTIER, Stijn, LOUTAS, Nikolaos. Op. Cit.}

406 _{BERNERS-LEE, Tim. Uniform Resource Identifier (URI): Generic Syntax. Op. Cit.} 407 _Ibid.

En outre, le choix d’une URI opaque ou signifiante est important :

 Les identifiants opaques sont intéressants car la sémantique a tendance à « pourrir »408 _{avec le temps, et à être difficilement gérable lorsqu’il y a plusieurs}

langues. De plus, ces identifiants peuvent être créés facilement de manière automatique et sont plus opérationnels lorsque l’on traite de grands jeux de données qui ont de hautes probabilités d’occasionner du « conflit » et de l’ambiguïté.

 Les identifiants signifiants sont manipulables, ils ont des métadonnées ad hoc, visibles et exploitables immédiatement. Ils sont plus indiqués pour les petits jeux de données ou des URL en contact avec l’utilisateur directement (nous l’avons vu avec la direction des Archives de France, par exemple).

« Il faut toujours se souvenir que les identifiants sont censés être traités à la fois par des machines et à la fois par des humains : ils devraient pouvoir être lus, épelés et écrits manuellement, mais également traités par des ordinateurs. »409

Certains identifiants tels que les identifiants ARK tentent de préserver les bénéfices de la signifiance et de l’opacité tout en retirant les contraintes 410_{: la}

proximité de l’identifiant opaque ARK avec ses métadonnées (il suffit par exemple de rajouter un « ? » à la fin lors du déréférencement pour obtenir celles-ci) permet d’obtenir une certaine souplesse. Les identifiants identifient mais ne définissent pas : ils dénotent, ils réfèrent, ils pointent vers quelque chose. Ce sont les métadonnées qui doivent jouer le rôle de descripteur.411

Ils ne sont cependant pas des dénominations non plus. « Associer absolument

des URI à une fonction de nom est trop lourd en plus d’être incorrect la plupart du temps ».412 L’idée perdure que le nom de domaine (et par extension les identifi ants web) ont une valeur de propriété et sont « équivalents à une valeur immobilière ». Les rachats de nom de domaine se comptent en millions (cas de pizza.com , par exemple, dont le prix est évalué à 2,6millions de dollars…413) et si le

cybersquatting* sur des marques déposées est illégal, il y a quand même une

économie qui se maintient autour du rachat et de la vente des noms. Ainsi, individualiser l’identifiant et le séparer du nom de domaine n’est pas une mauvaise idée, cela règle le problème évoqué par Ian Davis dans son article Is 303 really

necessary ? : si un serveur web cesse d’exister certaines informations seront perdues.

Afin de condenser ces quelques prérequis, ARK propose dans sa structure un lien entre trois composants : l’objet, ses métadonnées et une déclaration d’engagement. Ici la vision de l’identifiant est donc plurielle et tente d’englober l’ensemble des caractéristiques évoquées dans notre première partie : dénomination, localisation, contextualisation. C’est ce que l’on souhaite faire avec nos URI.

408 _{To rot en anglais, devenir obsolète, qui est lié au concept de link rot (phénomène d’obsolescence progressive} des liens qui deviennent des liens morts relativement utilisé dans la littérature professionnelle).

409 _{HILSE, Hans-Werner, KOTHE, Jochen. Op. Cit.} 410 _{KUNZE, John A. Op. Cit.}

411 _{BERGMAN, Mike. Op. Cit.} 412 _Ibid.

413 _{REES, Mark. Nom de domaine : 2,6 millions de dollars pour pizza.com. Site Next inpact.com [en ligne]} Disponible sur https://www.nextinpact.com/archive/42850-pizzacom-sedo-nom-domaine-record.htm [consulté le 09/08/2017]

3.3.3. Conseil n°3 : Assigner, « mapper » et penser le