Merci pour le pointeur vers le LDP, je vois qu’effectivement cela va dans la bonne direction.

Quand vous dites « Considérer que les entitées ne sont que des URIs est à mon avis une erreur », comment faudrait-il à votre avis les considérer ?

Sur l’aspect temporel, effectivement, HTTP fourni déjà la possibilité de faire une négociation de contenu en fonction de la date d’une ressource, c’est ce qu’exploite le framework mememtoweb en définissant le header « Accept-datetime », qui pourrait se généraliser à un numéro de version. Cela fournit/fournirait donc un moyen pour un client de récupérer l’état d’une ressource à une date donnée. Cependant pour pouvoir renvoyer une représentation des ressources d’un système à n’importe quelle date, il faut, dans le backend sous-jacent, avoir la capacité d’exprimer le fait que chaque triplet est associé à une certaine plage de validité. Cette possibilité n’est pas donnée par RDF, ce qui exclut de systèmes à base de RDF (sauf extensions propriétaires) dans ces backends. Sans parler de la possibilité d’interroger un endpoint SPARQL en lui demandant d’executer la requête avec l’état des données à un instant t.

En gros, par rapport à la temporalité, quand je disais que tous les projets demandent maintenant des fonctions de prise en compte des évolutions dans le temps, on rencontre les besoins suivants :

– besoin d’avoir une pise d’audit (savoir qui a fait quoi quand) (ce qui est adressé par le PROV-WG)
– besoin d’accéder à l’état d’une ressource à un instant arbitraire
– besoin d’interroger les données telles qu’elles étaient à un instant t arbitraire
– besoin de « tagger » des versions de données et de pouvoir accéder à une version précise des données

Pour ce qui est d’API ou de rendre la vie du développeur plus simple, je pense que LDP http://www.w3.org/2012/ldp/charter va dans la bonne direction.