La mutualisation de certains objets métas pour relier un objet à une propriété particulière, et notamment pour lui donner un type, nécessite une certaine forme d’abstraction.
Plusieurs questions sont en attente :
- Comment se présente le contenu d’un objet méta ?
- Quel vocabulaire pour l’objet méta ?
- La commutabilité des éléments d’un lien sont-ils possibles ?
- Comment représente-t-on l’impersonnalité dans l’objet méta ?
- Quelles contraintes sur le lien ?
Contenu d’un objet méta
Prenons un exemple :
– 365773b4f0588512 est l’objet contenant des informations, ici une image ;
– a6d344710a8313af est l’objet contenant le texte « image/png« , un type mime en fait.
Nous voulons exprimer le fait que 365773b4f0588512 est un objet de type mime a6d344710a8313af. Cela peut s’exprimer de plusieurs façons :
365773b4f0588512 est un objet de type mime a6d344710a8313af
365773b4f0588512 a pour type mime a6d344710a8313af
a6d344710a8313af est le type mime de 365773b4f0588512
a6d344710a8313af is type mime for 365773b4f0588512
365773b4f0588512 a, au nom de sa grande sainteté Beaubugg XIV, pour type mime a6d344710a8313af
365773b4f0588512 a reçu, par la grâce de dieu, en type mime a6d344710a8313af
365773b4f0588512 a pour type mime RFC2046 a6d344710a8313af
365773b4f0588512 a pour type mime RFC2048 a6d344710a8313af
Quelques bêtises dans cet exemple montrent surtout que, malgré le fait que l’on exprime la même chose, un vocabulaire est utilisé et qu’il n’est pas universel.
La mauvaise nouvelle, c’est que l’on va rapidement trouver des gens qui ont décidé de ne pas parler le même langage. La bonne nouvelle, c’est que des traductions sont faciles à mettre en place et que ça peut même être fait de façon transparente.
Ces différentes façons de s’exprimer sur le type mime d’une image sont représentées par des objets différents :
e53300deeffe3ec3
acef4b215ca8bba0
474925b937a0836a
85b7fff8a409dab5
cd1e1730de9235e6
6d43bd8a7d83f256
b56c357dd39e3adb
03dd321855febc4b
Un lien peut donc prendre avoir ces variantes (TimeStamp-Action-HashSource–HashCible–HashMeta-Signataire-0) :
201207061022-c-365773b4f0588512-a6d344710a8313af-e53300deeffe3ec3-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-acef4b215ca8bba0-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-474925b937a0836a-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-85b7fff8a409dab5-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-cd1e1730de9235e6-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-6d43bd8a7d83f256-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-b56c357dd39e3adb-e0196898b49716d1-0
201207061022-c-365773b4f0588512-a6d344710a8313af-03dd321855febc4b-e0196898b49716d1-0
Avec 201207061022 le timbre poste (timestamp) et e0196898b49716d1 l’entité qui a généré le lien.
On constate que le vocabulaire peut avoir une infinité de variante. Mais il est facilement traduisible dans le sens où on peut définir une équivalence directe entre tous ces « verbes ». Il en est de même si l’objet méta changeait, on peut facilement définir des équivalences.
Cette équivalence entre objets doit-elle être marqué sous forme d’un lien, ce qui la rend très rapide pour la traduction d’objets ? Ou peut-elle se contenter d’être représentée par un objet méta, ce qui veut dire qu’elle peut aussi avoir d’autres objets équivalents ?
Commutabilité
Dans l’exemple précédent, la relation entre les objets 365773b4f0588512 et a6d344710a8313af étant bien définit, la place des objets est interchangeable dans un lien.
Ces deux liens sont identiques :
201207061022-c-365773b4f0588512-a6d344710a8313af-e53300deeffe3ec3-e0196898b49716d1-0
201207061022-c-a6d344710a8313af-365773b4f0588512-e53300deeffe3ec3-e0196898b49716d1-0
Par contre, l’objet méta n’est pas échangeable dans le lien. Sinon il faudrait un autre moyen de le marquer comme étant un objet méta. Cet objet méta peut aussi être un objet source ou destination, il n’est donc pas « par défaut » un objet méta.
Du fait de cet exemple, la commutabilité semble possible dans un lien.
Impersonnalité
Prenons un autre exemple. L’exemple d’un objet supplémentaire contenant une image de type png, donc avec le même type mime.
L’exemple complet :
– 365773b4f0588512 est un objet contenant des informations, ici une image png ;
– 698055d556d44192 est un objet contenant des informations, ici une image png ;
– a6d344710a8313af est l’objet contenant le texte « image/png« , un type mime en fait.
Nous devons définir deux objets méta :
365773b4f0588512 est un objet de type mime a6d344710a8313af
698055d556d44192 est un objet de type mime a6d344710a8313af
Ce qui se traduit par deux objets différents :
e53300deeffe3ec3
90e65ecc9b0c7564
Et donc deux liens différents :
201207061022-c-365773b4f0588512-a6d344710a8313af-e53300deeffe3ec3-e0196898b49716d1-0
201207061022-c-698055d556d44192-a6d344710a8313af-90e65ecc9b0c7564-e0196898b49716d1-0
Nous avons deux objets méta différents alors que nous représentons la même opération, dire que l’objet source à un type mime « image/png ». Dommage, ce pourrait être le même. Mais ce lien est invalide car impossible à exploiter en pratique :
201207061022-c-365773b4f0588512-a6d344710a8313af-90e65ecc9b0c7564-e0196898b49716d1-0
Comment peut-on résoudre ce problème ?
Une première solution à ce problème est de fusionner le contenu de a6d344710a8313af dans l’objet méta en lieu et place de son hash. La fusion donne naturellement un nouvel objet qui n’est plus un objet méta mais un objet cible 1d27866a00a7c6e5 plus classique. Cela donne :
201207061022-c-365773b4f0588512-1d27866a00a7c6e5-e0196898b49716d1-0
Cependant, cette solution avait déjà été abandonnée dans une réflexion précédente. Elle implique que l’on doit systématiquement faire un traitement de cet objet pour en obtenir sa signification. Certe, on gagne un objet, mais on a toujours un nombre d’objets métas égal au nombre d’objets qui ont la même caractéristique (mis en valeur par le méta).
Deuxième solution, c’est possible avec l’impersonnalité.
Il faut rendre certains HashMeta universels, remplacer les HashSource et HashCible de ces objets métas par des « pointeurs » vers les objets sources et cibles des liens.
Définition de l’impersonnalité : Caractère de ce qui n’appartient à personne.
La solution de l’impersonnalité est la plus adaptée. On peut ainsi ne plus avoir que deux objets HashCible et HashMeta pour tous les objets qui partagent une même caractéristique (ici le type mime). Et on peut rapidement retrouver tous ces objets qui ont cette caractéristique commune.
Le format de ces pointeurs va dépendre du format utilisé pour le contenu de l’objet méta.
A définir donc…
Contraintes sur les liens
La commutation est possible dans les liens entre HashSource et HashCible avec des objets métas qui référencent directement ces hashs. C’est à dire que, pour un lien double ou triple, ces hashs peuvent être inversé indifféremment dans les liens que les entités vont garder.
Par contre, pour pouvoir disposer d’objets métas universels, la commutation n’est plus possible dans les liens entre HashSource et HashCible. Le lien doit être strictement le même partout.
Mais est-ce vraiment une contrainte?
On ne contredit pas une conclusion dans une réflexion précédente. Un lien étant créé par une entité dite « Signataire », et à plus forte raison si celle-ci appose une signature, les éléments de ce lien ne sont plus du tout interchangeable.
Deux liens présents, l’un sur un objet chez une entité, l’autre sur le même objet chez une autre entité mais avec HashSource et HashCible inter-changés, sont donc à considérer comme deux liens différents et non la recopie d’un même lien.
Conclusion
Heureusement, et c’est l’objectif, pour l’utilisateur tout se traduit plus simplement. Cet objet 365773b4f0588512 a sûrement un lien vers un objet qui définit son nom « user friendly », et est affiché comme une image parce qu’il a un type mime « image/png« .
Il faut trouver une syntaxe pour le contenu d’un objet méta.
Dans les liens, la commutabilité entre HashSource et HashCible n’est pas permise, définitivement.
L’impersonnalité est une caractéristique importante, et doit pouvoir être représenté dans la syntaxe du contenu des objets métas.
NB : Les hashs sont des valeurs MD5 calculées sur les textes ou de vrais fichiers. Seule la première moitié du hash est affiché pour ne pas surcharger la page. En fait, on aurait même pu ne prendre que les quatre premiers digits, ça fonctionnait. Les valeurs sont donc cohérentes mais n’ont de toute façon pas d’importance ici, seul compte le raisonnement.