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¶
![_images/Carandache.png](_images/Carandache.png)
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 :
Illustration¶
![_images/punning-hash-uris.png](_images/punning-hash-uris.png)
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¶
![_images/punning-303.png](_images/punning-303.png)