Voici la 3e partie de ma traduction du tutorial écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

3 – Choisir les URI

Les ressources sont nommées avec des références URI. Quand vous publiez des données liées, vous devez consacrer un certain effort au choix de bons URI pour vos ressources.

D’une part, ils doivent être de noms que d’autres éditeurs pourront utiliser en toute confiance pour lier vos ressources à leurs propres données. D’autre part, vous aurez à mettre en place l’infrastructure technique afin de les rendre déréférençable, et cela peut ajouter quelques contraintes sur ce que vous pouvez faire.

Cette section énumère quelques éléments à garder à l’esprit.

  • Utilisez les URI HTTP pour tout. Le schéma Http:// est le seul à être largement utilisé dans les outils et les infrastructures actuels. Tous les autres schémas exigent un effort supplémentaire pour la résolution des services Web, qui utilise des répertoires d’identifiant, et ainsi de suite. Les arguments en faveur de l’utilisation du protocole HTTP sont discutés en plusieurs endroits, par exemple dans noms et adresses de Norman Walsh, et URN, espaces de noms et répertoires (projet) du W3C TAG.
  • Choisissez vos URI dans un espace de noms HTTP sous votre contrôle, où vous pouvez les rendre effectivement déréférençable. Ne les définissez pas dans l’espace de noms de quelqu’un d’autre.
  • Evitez les trucs qui concernent la réalisation dans vos URI. Bref, les noms mnémoniques sont meilleurs. Considérons ces deux exemples :
    • http://dbpedia.org/resource/Berlin
    • http://www4.wiwiss.fu-berlin.de:2020/demos/dbpedia/cgi-bin/resources.php?id=Berlin
  • Essayez de garder vos URI stables et persistants. Modifiez plus tard votre URI brisera tous les liens déjà établis, il est donc conseillé de leur consacrer une pensée supplémentaire à un stade précoce.
  • Les URI que vous pouvez choisir sont limitées par votre environnement technique. Si votre serveur est appelé demo.serverpool.wiwiss.example.org et qu’obtenir un autre nom de domaine n’est pas possible, alors votre URI devra commencer par http://demo.serverpool.wiwiss.example.org/. Si vous ne pouvez pas exécuter votre serveur sur le port 80, votre URI devra commencer par http://demo.serverpool.example.org:2020/. Autant que possible, vous devez nettoyer ces URI en ajoutant quelques règles de réécriture d’URI à la configuration de votre serveur Web.
  • Nous finissons souvent avec trois URI relatives à une simple ressource non-informative :
    1. un identifiant pour la ressource,
    2. un identificateur pour une ressource informative liée qui soit adaptée aux navigateurs HTML (avec une représentation de page Web),
    3. un identificateur pour une ressource informative liées qui soit adaptée aux navigateurs RDF (avec une représentation RDF/XML).

      4. Voici plusieurs idées pour le choix de ces URI associés :

    1. http://dbpedia.org/resource/Berlin
    2. http://dbpedia.org/page/Berlin
    3. http://dbpedia.org/data/Berlin

      4. Ou

    1. http://id.dbpedia.org/Berlin
    2. http://pages.dbpedia.org/Berlin
    3. http://data.dbpedia.org/Berlin

      4. Ou

    1. http://dbpedia.org/Berlin
    2. http://dbpedia.org/Berlin.html
    3. http://dbpedia.org/Berlin.rdf
  • Vous aurez souvent besoin d’utiliser une sorte de clé primaire à l’intérieur de votre URI, pour s’assurer que chacun est unique. Si vous le pouvez, utilisez une clé qui est significative de votre domaine. Par exemple, si vous traitez de livres, le recours à une partie du numéro ISBN dans l’URI est mieux que l’utilisation d’une clé primaire venant d’une table de base de données interne. Cela facilite également l’interprétation d’équivalence pour obtenir des liens RDF dérivés.

Exemples d’URI cool :

Voir aussi :