Sous nebule, les objets sont référencés par leur empreinte. Ça ressemble quelque part au référencement des fichiers par des inodes sur les systèmes de fichiers UNIX.
Chemins
Dans un système de fichier, nous avons aussi impérativement besoin de deux autres choses pour retrouver le contenu.
Le premier est le nom, qui peut être aussi l’empreinte du fichier, moyennant la vérification par les liens de parentés de la disponibilité de versions plus récentes de ce « fichier » (de son contenu en fait). Voir plus bas.
La deuxième chose impérative est le chemin. Il permet surtout de retrouver facilement le fichier par rapport à un contexte (nom des répertoire de l’arborescence) et éventuellement de le placer à plusieurs endroits de l’arborescence (contextes différents).
Liens
Deux façons de rattacher ces chemins à un fichier.
La première est d’utiliser des tags (privés), ce qui rend ce chemin invisible et non transmissible aux entités externes.
La deuxième est d’utiliser les liens justement. Leur diffusion est native avec possibilité de restriction.
Noms
Le nom de fichier est souvent (mais pas obligatoirement) le reflet du contenu du fichier. Le reflet non pas sous forme d’empreinte mais sous forme d’information.
Il faut pouvoir retrouver un fichier en fonction des informations qu’il contient, et pas seulement en fonction du contexte (chemin). En interne, les tags permettent de gérer les objets en fonction des informations.
Plus généralement, un objet peut être lié à d’autres objets et peut donc facilement être retrouvé. Un objet qui n’a pas de lien est un objet qui n’a pas d’utilité. Le chemin sous forme de lien est une autre façon de lier ces objets partageant un même contexte.
Restrictions
Et les droits? Les restrictions?
Elles sont nativement gérées par les objets et les entités.
Conclusion
Techniquement, cela paraît viable :-)