Annexes

Sémantique des URIs HTTP

Problème

• D’après les principes du Linked Data, tout objet d’intérêt devrait avoir un URI déréférenceable (en général http:)

  • y compris une personne, une organisation, un lieu, un concept…

• Or dans la sémantique de HTTP, une ressource est un objet informatique.

→ Ce problème est connu sous le nom httpRange-14

httpRange14

par Caran d’Ache et Ivan Herman

Solution 1 : identificateurs de fragment

• Un URI peut contenir un identificateur de fragment (fragid), commençant par #

• HTTP ignore les identificateurs de fragments (ils ne sont même pas envoyés au serveur)

  • donc la sémantique d’un URI contenant un fragid n’est pas contrainte par HTTP :

  • http://champin.net/  ≠  http://champin.net/#pa

Illustration

source: http://www.jenitennison.com/blog/node/170

Problèmes en suspens

• La sémantique du fragment est normalement spécifiée par le type de contenu, ce qui pose problème notamment pour la négociation de contenu (types de contenus multiples).

• Dans certains types de contenu, la sémantique du fragment est contrainte :

  • XML, HTML → sous-arbre de l’arbre DOM

  • ce qui pose problème pour RDFa…

Solution 2 : redirection

• Un code de retour 200 OK signifie qu’on a affaire à une ressource au sens de HTTP (information resource)

  • Tout autre code n’engage pas HTTP sur la nature de la ressource.

• Si l’URI identifie un autre type de ressource (non information resource), il doit utiliser une redirection via 303 See Also

  • ce qui peut impliquer de la négociation de contenu pour s’adapter au client.

  • exemple : http://dbpedia.org/resource/Lyon

    redirige vers http://dbpedia.org/data/Lyon (RDF)

    ou http://dbpedia.org/page/Lyon (HTML)

Illustration

source: http://www.jenitennison.com/blog/node/170