Le lien étant la partie essentielle du partage de l’information, il doit être définit pour répondre exactement à ce rôle. C’est un des trois piliers de Nebule.
Par essence, sa définition se doit aussi d’être précise et universelle.
Étudions quelques cas…
Lien simple
Le lien dans sa forme la plus simple fait la liaison entre deux objets, sans méta données. Il est là pour lier deux objets sans plus de précision.
D’un point de vue informations, le lien simple contient :
- un datage ;
- une action création/annulation/suppression ;
- le hash de l’objet source ;
- éventuellement le hash de l’objet cible ;
- éventuellement le hash de l’objet méta ;
un hash de l’entité signataire ;une signature.
La gestion des liens nécessite de définir une action. Cette action ne doit pas être de nature à compromettre la confidentialité des objets. Il faut définir les autres actions de base possibles pour un lien.
L’action, comme sous ensemble du lien, est validée par une signature. Pas de signature = action douteuse…
Lien double vers objet
Le lien double est constitué de deux liens simples symétriques. Le premier lien est attaché à un objet et désigne un deuxième objet. Le deuxième lien est attaché au deuxième objet et désigne le premier objet.
Les deux liens attachés aux deux objets doivent être identiques. Les deux liens pourraient être symétriques, à condition de ne pas être signés. Cela pose trop de problèmes, notamment, ils ne sont plus considérés comme les deux liens simples d’un seul lien double.
En fait, en l’absence de méta-données, le lien double est la norme. Le lien simple ne sera vraiment utilisé que dans des environnements non coopératifs, où l’entité qui a généré l’objet cible du lien ne reconnaît pas les liens générés par l’entité qui a généré l’objet source.
Lien double vers objet méta non typé
Prenons l’exemple du schéma ci-dessous :
Cela représente plusieurs objets centrés sur deux objets principaux que sont une Image et une Icône.
Il faut ajouter des liens vers des objets méta afin de définir les objets, et donc de permettre leur traitement.
Les liens tels que faits ici sont maladroits. Nous sommes dans un cas général dans lequel il n’y a pas de conflit entre les propriétés des valeurs liées aux objets. Ils partagent même des propriétés. Mais que ce passe-t-il si une même valeur doit être rattachée à deux propriétés différentes? Comment résoudre à posteriori la propriété à appliquer à la valeur?
Cette méthode est rapidement inutilisable, c’est rédhibitoire.
Lien double vers objet méta typé
Prenons un autre exemple dérivé du précédent en essayant de corriger le problème :
Là , valeurs et propriétés ont été fusionnées dans des objets méta. Plus d’ambiguïté possible.
Mais peut-on l’améliorer?
Lien double vers type
Autre exemple dérivé du premier schéma :
On retombe avec le même problème d’ambiguïté entre plusieurs valeurs rattachées à la même propriété.
On remarque cependant que l’on peut peut-être essayer d’associer un couple valeur/propriété à un objet…
Lien triple vers méta et type
Nouvel exemple en associant le couple valeur/propriété à un objet :
On n’a pas d’ambiguïté. Ce schéma est aussi valable.
Par rapport au deuxième schéma, valide lui aussi, on peut gagner aussi en nombre d’objets autour des objets centraux Image et Icône. Les objets méta peuvent être réutilisés.
Les objets correspondants à des valeurs peuvent être utilisés simultanément par plusieurs objets sans ambiguïté.
Les objets correspondants à des propriétés peuvent, moyennant l’introduction d’une particularité, être utilisés simultanément avec plusieurs valeurs pour plusieurs objets différents. La particularité étant d’accepter des objets source et cible inconnus. L’opération réalisée par l’objet propriété est appliquée à la source et à la cible du lien que l’on utilise, et non à tel objet source et tel objet cible de façon pré-défini.
Ces objets méta deviennent ainsi génériques et sont appliqués par rapport aux objets sources et cibles définis par les liens.
On gagne dans ce cas potentiellement énormément d’objets, c’est autant d’objets qui n’auront pas besoin d’être stockés, traités, échangés…
Registre de lien
Chaque objets dispose de méta données. Ces méta données sont les liens, dans leur forme simple.
Un lien peut être représenté par une sorte de ligne de registre de la forme :
1: ((TimeStamp-Action-HashSource-HashCible–HashMeta–Signataire)–Signature)
Ou par des formes simplifiées, si on rend optionnel HashCible, HashMeta, Signataire et Signature :
2: (TimeStamp-Action-HashSource-HashCible–HashMeta–Signataire)
3: ((TimeStamp-Action-HashSource-HashCible–Signataire)–Signature)
4: (TimeStamp-Action-HashSource-HashCible–Signataire)
5: (TimeStamp-Action-HashSource-HashCible–HashMeta)
6: ((TimeStamp-Action-HashSource-Signataire)–Signature)
7: (TimeStamp-Action-HashSource-Signataire)
8: (TimeStamp-Action-HashSource-HashCible)
Le cas 8 ne pose pas de problème, c’est le cas le plus simple.
Les cas 1 et 2 sont sans ambiguïté pour l’ordre des champs. Le cas 1 pose cependant un petit problème pratique pour la signature. Cette signature est calculée pour tous les champs, dans cet ordre et sans ajout ou suppression d’espace, à l’exception du champ signature (puisque pas encore calculé). Ou bien il peut être calculé pour tous les champs mais avec une signature prépositionnée nulle.
Les cas 3 et 4 sont identiques à la signature près.
Les cas 4 et 5 sont ambigus, sauf si on considère que le signataire est un objet méta. Ne contenant pas de quoi faciliter le traitement du lien entre objets source et destination, l’objet signataire sera vu comme un objet méta neutre ou inutilisable, mais pas invalide pour autant.
Le cas 6 est ambigus par rapport aux cas 4 et 5. Non que le signataire ne puisse être l’objet cible, mais parce que la signature ne peut être le hash d’un objet existant. Le même problème existe entre les cas 2 et 3.
Le cas 7 est finalement identique au cas 8. Le signataire, sans valider le lien par une signature, définit un lien direct et sans autre forme de précision entre l’objet source et lui-même.
Signature
Le champs signature est source d’ambiguïté. On peut l’isoler, est lui faire signer les autres champs, mais ce n’est pas le plus pratique. Comme l’isoler? Le tagger? La forme XML du registre peut répondre à cette question.
On peut aussi imposer le champs signature. Certe on ne peut pas imposer la signature, mais au moins le champs. Si pas de signature, il est positionné nul et le champ précédent à une signification HashMeta, HashCible ou Signataire. Si non nul, c’est une signature est doit être considéré comme telle, et le champs précédent est à considérer comme étant le Signataire.
Du coup, le champs passe de éventuel à obligatoire, même si c’est sa forme la plus réduite « 0 ». Cette obligation ne portera pas trop à préjudice puisque les liens non signés seront par nature douteux et donc la plupart du temps ignorés.
Cela donne donc les possibilités de registre suivant :
1: (TimeStamp-Action-HashSource-HashCible–HashMeta–Signataire–Signature)
2: (TimeStamp-Action-HashSource-HashCible–HashMeta–Signataire–0)
3: (TimeStamp-Action-HashSource-HashCible–Signataire–Signature)
4: (TimeStamp-Action-HashSource-HashCible–Signataire–0)
5: (TimeStamp-Action-HashSource-HashCible–HashMeta–0)
6: (TimeStamp-Action-HashSource-Signataire–Signature)
7: (TimeStamp-Action-HashSource-Signataire–0)
8: (TimeStamp-Action-HashSource-HashCible–0)
Signataire
Quel peut être l’utilité d’un lien entre deux objets si il n’y a pas le marquage de l’entité qui a créé ce lien, le Signataire?
Un lien validé par une entité que l’on ne connaît pas, et donc que l’on ne peut pas vérifier, c’est différent du lien qui n’est fait par personne.
Il aura toutes les chances d’être rejeté, même en environnement clôt et sans signatures.
Le Signataire dit qui l’a généré, il est obligatoire de fait.
Cela réduit le nombre de possibilités du registre :
1: (TimeStamp-Action-HashSource-HashCible–HashMeta–Signataire–Signature)
2: (TimeStamp-Action-HashSource-HashCible–HashMeta–Signataire–0)
3: (TimeStamp-Action-HashSource-HashCible–Signataire–Signature)
4: (TimeStamp-Action-HashSource-HashCible–Signataire–0)
5: (TimeStamp-Action-HashSource-Signataire–Signature)
6: (TimeStamp-Action-HashSource-Signataire–0)
Cela lève-t-il l’ambiguïté que l’on avait avec la Signature? Peut-on de nouveau se passer du champs Signature? En fait, non. Les ambiguïtés entre les cas 5 et 4 (sans 0) par exemple sont bloquantes.
Taille des champs
Tous les champs ont potentiellement des longueurs variables.
Le champs TimeStamp à une longueur qui dépend de la norme d’affichage incluant par exemple la Time Zone ou une précision améliorée.
Le champs Action est normalement de 1 caractère, mais rien n’empêche d’utiliser un vocabulaire plus large. Cependant ce n’est pas vraiment recommandé, le vocabulaire des liens doit rester extrêmement simple. Le mieux serait de le maintenir à un seul caractère ou de ne tenir compte que du premier caractère.
Les champs HashSource, HashCible, HashMeta et Signataire sont variables mais dépendants des fonctions de hashage.
Le champs Signature à aussi une longueur variable et dépendante des fonctions de hashage, notamment plus particulièrement celle qui fera le hash de tous les champs avant le calcul de la signature.