Archive for the ‘noeuds’ Category

Définition des groupes

Jeudi, janvier 14th, 2016

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

Nœud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.

Nommage multiple et protéiforme

Vendredi, juillet 18th, 2014

Dans nebule, les objets ont forcément un identifiant. Ils ont aussi parfois un nom. Typiquement, c’est le cas lorsque l’objet a pour source un fichier nébulisé.

shot-2014-07-18_20-07-59

Le nom est un texte de caractères compréhensible par les humains. Déjà, en fonction des langues, il se peux que ce texte ne soit pas compréhensible pas tout le monde. Mais on exclut déjà par principe les caractères non imprimables, même si en réalité ça n’a pas beaucoup d’importance. Il vaut mieux que le texte n’ai pas de retour à la ligne, mais ça peut être interprété, traduit et pris en compte à l’affichage.

Pour un fichier, le nom (qui inclus le chemin) a deux rôles :

  1. le classement sommaire par sujets en fonction du chemin et parfois du nom ;
  2. la description sommaire du contenu, un peu comme un titre.

Dans nebule, le nom que l’on peut donner à un objet a le même rôle que le nom pour un fichier. Il donne un titre à l’objet. Par contre, le classement des objets intervient peu avec le nom que ceux-ci pourraient avoir. Ce serait plutôt le rôle de groupes et de nœuds, concept encore en cours d’affinement. Pour un objet, lui donner un nom c’est le lier à un autre objet qui contient le nom avec un lien de type l.

Si un fichier ne peut avoir qu’un seul nom, un objet peut en avoir plus. Il est possible de créer plusieurs liens vers différents objets à utiliser comme noms. Les propriétés de liens multiples et concurrents sont valables aussi pour le nommage.
Lors de l’affichage, comme dans l’exemple ci-dessus, il faut faire un choix. Soit on affiche tous les noms, ce qui peut rapidement devenir problématique et difficilement compréhensible par l’utilisateur. Soit on affiche qu’un seul nom, celui affiché étant celui qui a le plus grand score dans le calcul des relations sociales. C’est cette dernière solution qui est adoptée aujourd’hui.

Mais on peut faire encore mieux. Rien n’interdit un lien pour un titre de renvoyer vers une image. D’ailleurs, ce peut être tout objet sans distinction. C’est l’interprétation du titre qui ici prend son importance. Si on n’interprète que du texte alphanumérique sur une seule ligne, les autres objets seront ignorés comme titre.
Si on décide de prendre en compte aussi les images, il ne sera peut-être pas opportun d’utiliser une image de grande résolution, lourde. On peut utiliser à la place les miniatures, des images dérivées, pour l’affichage comme titre. Les miniatures d’images seront d’ailleurs très régulièrement utilisées lors de l’affichage.
Pour un film, on va peut-être utiliser soit une image fixe soit une petite séquence animée, l’une comme l’autre extraite du film.

L’affichage final peut dans certains cas prendre en compte simultanément plusieurs objets titres mais de types différents. Par exemple accepter une image et un texte, ou un morceau de film, un son et un texte…
Protéiforme ne veut pas dire en forme de protéine mais bien de formes multiples.
Tout est question d’interprétation et de stratégie d’affichage. Tout est possible, aussi.

Dans sylabe, comme dans nebule, une entité a un nom constitué d’un petit texte, un prénom et même un préfixe sur le même principe. Mais elle peut aussi depuis peu avoir une image, typiquement une photo d’identité. Le nommage multiple et protéiforme existe donc déjà.

Appartenance et/ou propriété – suite

Samedi, novembre 2nd, 2013

Suite de Appartenance et/ou propriété.

En regardant le code de sylabe et notamment la façon dont on traduit les liens, on voit une énorme instruction switch pour trier les liens de type l. Ce tri est fait par rapport à l’objet méta. Les liens sans objet méta (càd égale à 0) apparaissent donc comme des exceptions qu’il faut gérer dans un autre sous switch.

D’un autre côté, les liens de type f sont triés plus naturellement par l’objet source. Cela n’a donc pas d’importance si l’objet méta est nul.

Donc, c’est un lien de type f qui sera maintenant à utiliser pour désigner un nœud. Cela devient un groupe à part entière.

Tous les liens de type l avec un objet méta nul sont marqués comme périmés. Il n’y a plus de moyen de désigner explicitement un objet comme ‘objet‘, ‘entité‘ ou ‘objet de suivi spécifique‘. Et il n’y a pas vraiment besoin.
Il est ajouté dans la documentation nebule v1.1 que les liens de type l ne devraient avoir ni un objet méta nul ni un objet destination nul.

Appartenance et/ou propriété

Samedi, novembre 2nd, 2013

Il se pose un dilemme aujourd’hui dans la définition de ce qu’est un nœud. Non sur la nature de celui-ci mais plutôt sur la façon dont le nœud est désigné comme tel.

Le même genre de problème se pose aussi pour une entité mais de façon un peu plus simple.
Une entité est capable de signer, c’est donc avant tout une clé cryptographique asymétrique (RSA uniquement aujourd’hui dans nebule). C’est aussi plus spécifiquement la clé publique, celle que l’on diffuse, donc celle par laquelle on est connu et reconnu. Au delà de ses propriétés mathématiques internes, elle est reconnu par la forme de son contenu et plus généralement par son type mime : ‘application/x-pem-file‘. Malheureusement, le fichier PEM, qu’il contienne la clé publique ou la privée ou les deux, a toujours le même type mime. Il est impossible de distinguer l’une ou l’autre naturellement par le type mime, il faut regarder le contenu pour pouvoir prendre une décision sur la nature de la clé.
Cela paraît compliqué comme ça, mais le problème est finalement facile à résoudre. Pour savoir si c’est une entité, il suffit de regarder si l’objet a le bon type mime puis de lire la première ligne du fichier (moins de 30 caractères). On peut vouloir ajouter un lien pour dire explicitement que cet objet est une entité. Mais quel doit être ce lien? Un lien de type l pour attribuer un attribut à l’objet? Ou un lien de type f pour dire que l’objet fait parti (dérivé) du groupe des entités?

Il y a le même problème avec le nœud. Celui-ci n’a pas de type mime à proprement parler, ce peut être du texte comme une image. Il peut être tentant d’ajouter un lien pour définir explicitement un objet comme étant un nœud. Dans ce cas, la recherche des nœuds est facilité puisqu’il suffit de regarder les liens vers l’objet ‘nebule/objet/noeud‘. On en revient cependant aux mêmes questions. Quel doit être ce lien? Un lien de type l pour attribuer un attribut à l’objet? Ou un lien de type f pour dire que l’objet fait parti (dérivé) du groupe des entités?
Il s’ajoute un autre problème. Nous n’avons pas besoin en théorie de ce lien pour caractériser un nœud. Il suffit que le nœud ai au moins un liens de type f pour lequel il est à la fois l’objet source et l’objet méta. Mais pour retrouver les nœuds, cela oblige à parcourir tous les objets. Bref, ce n’est pas réalisable en pratique pour un usage commun. Nous devons donc ajouter un lien qui explicite la nature de nœud de l’objet.

Les deux type de liens sont équivalents pour résoudre ce problème. Le type l est plus simple. Le type f permet quand à lui de voir la notion de nœud comme un groupe. Est-ce qu’il y a un intérêt à gérer les nœuds dans un groupe?
L’usage seul nous permettra de déterminer quel est le meilleur type de lien…

Nœud et groupe

Jeudi, juillet 25th, 2013

Dans l’utilisation qu’il en est faite dans nebule, quelles sont les différences entre les concepts de nœud et de groupe ?

Les deux sont séparés dans le code de sylabe, mais est-ce bien raisonnable ?

Le weblog et la relation d’objets – 2

Jeudi, juillet 11th, 2013

Suite de la réflexion sur le weblog et la relation d’objets.

La première expérience avec sylabe sur une arborescence d’objets liés montre qu’il faut privilégier les liens de type dérivation f dans cet usage. Le lien de type l permet avec un objet méta de déterminer la relation entre deux objets dans l’arborescence. Mais c’est déjà ce que fait le lien de type dérivation f sans objet méta. Et si l’emplacement de l’objet méta est utilisé, il n’est du coup pas possible de définir ce que l’on peut appeler un contexte. C’est à dire de définir que les deux objets sont dans une arborescence bien délimitée et non tout le temps liés.

Ensuite, des liens de type dérivation f peuvent être utilisés sans objet méta afin de définir un objet dérivé d’un autre de façon générale. La différence, c’est que sans objet méta, le lien n’est pas utilisé dans l’affichage d’une arborescence d’objets. Mais cela n’empêche pas qu’ils soient utilisés pour améliorer l’affichage de certains objets spécifiques dans la représentation de l’arborescence. Ainsi, une arborescence d’images de grandes tailles gagnera à voir chaque image remplacée une à une par une versions réduite. C’est plus adaptée à l’affichage d’un navigateur web par exemple. La version réduite de chaque image étant liée à l’image originale par un lien de dérivation f.

Cette façon de faire résout les cas de gestion d’un article dans plusieurs nœuds et de gestion d’un article à plusieurs endroits dans le même nœud.

Reste à définir le cas de la gestion d’un nœud sous un autre nœud.

Le weblog et la relation d’objets

Jeudi, juillet 4th, 2013

La mise en application des objets et liens nebule dans sylabe montre qu’un aspect important de la relation entre les objets a été sous-estimé.

Prenons l’exemple d’un blog ou d’un fil de discussion sur FB (en autres). Un utilisateur publie un article, un texte en fait. A cet article, tous les utilisateurs (ou presque) peuvent répondre, c’est à dire attacher à l’article un nouvel article. Ce nouvel article est aussi un texte, mais il est subordonné à l’article initial.
On peut ainsi ajouter une infinité d’articles subordonnés à l’article initial ou subordonnés les uns aux autres.

Première remarque à priori. L’article initial, celui de plus haut niveau, a tout intérêt à être déclaré comme étant un nœud. Mais ça n’est pas obligatoire en fait.

Ensuite, le lien entre l’article initial et les articles qui lui répondent est un lien créant une hiérarchie. Les liens nebule de type l ou f peuvent répondre à ce besoin.

La réflexion est cependant incomplète. Il faut tenir compte de :
– la gestion d’un article dans plusieurs nœuds ;
– la gestion d’un article à plusieurs endroits dans le même nœud ;
– la gestion d’un nœud sous un autre nœud.

A suivre…

Nœuds

Samedi, septembre 15th, 2012

Le nœud est la rencontre de plusieurs chemins convergents/divergents. Cette rencontre est matérialisé par une liaison forte entre ces différents chemins.

La nébuleuse des objets a besoin d’une architecture locale avec des points de convergence forts. Ce sont des nœuds. Ils permettent d’architecturer, d’organiser les liens entres objets, et donc de canaliser les partages d’informations.