Archive for the ‘pondération’ Category

Objets privés et fonctionnement interne

Jeudi, mars 14th, 2013

Il existe des informations que l’on ne peut gérer par les liens nebule sous peine de fortement complexifier son fonctionnement, et donc la compréhension que l’on en a dans son ensemble.

Par exemple, c’est le cas pour mettre un poids à un objet. C’est à dire lui attribuer une méta information qui décrit son importance relative aux autres objets. C’est une notation en quelque sorte.
Un poids peut être fixé arbitrairement. Ce n’est pas le meilleur cas même si c’est réalisable en pratique. Le poids d’un objet a surtout de forte chance de refléter l’importance que l’on donne à cet objet. A cet objet pondéré sont liés d’autres objets. Ces autres objets, si leurs poids ne sont peut-être pas explicitement définis, vont hériter d’une moyenne des poids des objets autour. Ainsi, un objet va gagner de l’importance si il est lié à un objet jugé (donc pondéré) très important.
De ce poids peut en découler des conséquences concrètes. Par exemple si l’on permet l’oublie et l’effacement d’objets anciens de façon calculé et contrôlé, la pondération permet de conserver très longtemps un objet important.

Cette pondération des objets qu’une entité va réaliser est un travail ‘personnel’. Le fruit de ce travail peut avoir un intérêt public. Et une autre entité ayant fait le même travail ne donnera pas les mêmes pondérations.
Cependant, une partie de ce travail de pondération peut être jugé privé. Si le partage d’une pondération d’objets peut être réalisée simplement par des liens, comment protéger les pondérations privées ?

Une des possibilités est d’exploiter les objets stockants des liens.

Mémoire fini

Mardi, avril 5th, 2011

On part souvent du principe que l’on va gérer nos données en les accumulant dans le temps de façon infinie…

Mais est-ce vrai?

C’est en partie vrai.

Les capacités de stockage évoluent assez rapidement dans le temps. Nous enregistrons de nouveaux fichiers assez régulièrement dans le temps mais pas forcément de façon continu. Ici, pour la réflexion, on ne va retenir qu’une moyenne constante d’enregistrement de données.

Que se passe-t-il si on ajoute régulièrement suffisamment de capacités de stockage, suffisamment pour ne jamais arriver à saturation?
Tout se passe bien, on ne perd rien.

Et si la capacité de stockage n’augmente pas assez vite (dans le cas extrême où elle ne peut plus être augmentée) ?
C’est dans ce cas que doit être prévu un mécanisme de nettoyage (d’oubli), et donc de pertes maîtrisées.

Le stockage de données sous la forme proposée pour nebule risque dans certains cas de générer, et donc de stocker, énormément de données. On doit prévoir ce mécanisme d’oubli nativement.

La perte d’information maîtrisée impose de permettre cette gestion à la main. Mais quelle efficacité d’une gestion à la main pour plusieurs millions de fichiers?
Des mécanismes d’assistance ou d’automatisation doivent être proposés. Ils peuvent avoir plusieurs formes.

Sur quels critères déclarer un fichier périmé?
Plusieurs critères peuvent être pris en compte, et plusieurs combinaisons complexes peuvent être calculées de critères simples :
– le temps de possession de l’objet, plus il est vieux plus il a de chance d’être périmé ;
– si le fichier dispose d’une nouvelle version, il n’est peut-être plus intéressant de le conserver ;
– l’attractivité, ou un critère d’appréciation, donne de l’importance à un fichier dans le temps et doit faciliter sa conservation ;
– l’intensité de l’appréciation peut être exploitée en absolu, un fichier qui appel un très fort sentiment positif ou négatif a des chances de devoir être conservé longtemps ;
– un fichier lié à plusieurs autre fichiers jugés importants a surement besoin d’être lui aussi conservé, il va peut-être hériter par calcul d’une note d’appréciation ;
– d’autres fichiers font références à ce fichier, il faut sûrement le conserver ;
– mes amis ont gardé ce fichier, il doit être important.

Doit-on supprimer immédiatement un fichier périmé?
Celui-ci peut peut-être servir à quelqu’un d’autre? A-t-on la place de le garder en attendant? Peut-on se contenter de le supprimer lorsque l’on aura besoin de la place qu’il occupe? Doit-on les marquer périmés en attendant ou gérer une liste des objets périmés?
L’analyse des fichiers à marquer peut se faire en continu, moyennant une occupation constant et relativement importante de ressources. L’analyse peut se faire lors d’une phase de repos (activité de sommeil). Une liste peut aussi être maintenu en temps réel sans analyse, juste en classant les objets de façon croissante dans une liste et en faisant évoluer la place des objets en fonction de l’évolution de leurs paramètres.

Une fois un objet marqué comme périmé, comme propager son marquage? C’est à dire, comment vont se comporter les relais avec ces objets dits périmés?
Cette propriété de péremption doit-elle être visible des entités tierces? Ou est-elle purement interne?