C’est exact!
Mais réfléchissons-y tout de même!
Avant-propos
Je ne suis pas un expert SPARQL, donc soyez indulgents…
Requête SPARQL locale
Supposons que vous ayez une base de données RDF légère sur votre ordinateur, par exemple tracker3.
Ajoutez votre propre table de café à votre base:
PREFIX schema: <http://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
## Suppression de la précédente version de la table, si elle existe
DELETE DATA
{
GRAPH <jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/rdf-source>
{
<jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/public/meeting/2024-08-15T14:00:00Z> ?p ?o .
}
}
## Création d'une nouvelle version de la table
INSERT DATA
{
GRAPH <jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/rdf-source>
{
<jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/public/meeting/2024-08-15T14:00:00Z>
schema:name <jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/public/profile/name.txt> ;
schema:image <jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/public/profile/img.jpg> ;
schema:inLanguage <jami://916fea7fe3b6111464e2a961a46742406a3ae2b8/public/profile/default-language.txt> ;
schema:maximumVirtualAttendeeCapacity 4 ;
schema:remainingAttendeeCapacity 3 ;
schema:dateReceived "2024-08-15T14:00:00Z"^^xsd:dateTime ;
schema:endDate "2024-08-15T16:00:00Z"^^xsd:dateTime .
}
}
Requête SPARQL sur un swarm publique
Maintenant, comment déclarer votre table sur le réseau?
Supposons un swarm assez grand, réunissant par exemple tous les francophones du réseau.
Postez la requête SPARQL sur ce swarm.
Évidemment, les destinataires ne peuvent pas exécuter la requête SPARQL directement, car plusieurs informations doivent être modifiées ou vérifiées, et cela poserait des problèmes de sécurité.
Premièrement, la source rdf indiquée par l’instruction GRAPH ne peut pas être celle de l’expéditeur.
En effet, un destinataire va modifier sa source rdf locale dans sa propre base de données, et non celle de l’expéditeur.
Donc dans l’instruction GRAPH, il va modifier l’id de l’expéditeur par sa propre id.
Deuxièmement, il doit vérifier si l’expéditeur a bien le droit de modifier les propriétés de cette table de café.
Pour déterminer ce droit, la règle la plus simple est que l’expéditeur ne peut modifier que sa propre table.
Par conséquent, le destinataire vérifie que les ID des autorités correspondent bien à l’ID de l’expéditeur.
Après avoir effectué toutes ces modifications et vérifications, le destinataire, pourrait, en principe, exécuter la requête pour enregistrer la table de l’expéditeur dans sa base de données.
Mais cela doit être absolument proscrit, puisque la requête SPARQL pourrait contenir des requêtes malicieuses.
Modèles de requête SPARQL pré-enregistrés localement et exécutés localement
Toutes les requêtes SPARQL utilisées pour enregistrer des tables de café ont à peu près la même structure.
Des modèles de ces requêtes peuvent donc être pré-enregistrés localement et identifiés sur le réseau par un code.
L’expéditeur peut donc envoyer uniquement le code d’identification de sa requête, et non la requête elle-même, à charge pour le destinataire de construire la requête SPARQL correcte à partir de l’id de l’expéditeur, de sa propre id, des paramètres du swarm et de ses propres paramètres locaux.
Un modèle de requête SPARQL pourrait ressembler à ça:
PREFIX schema: <http://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
DELETE DATA
{
GRAPH <jami://$RECIPIENT-ID/rdf-source>
{
<jami://$SENDER-ID/public/meeting/2024-08-15T14:00:00Z> ?p ?o .
}
}
INSERT DATA
{
GRAPH <jami://$RECIPIENT-ID/rdf-source>
{
<jami://$SENDER-ID/public/meeting/2024-08-15T14:00:00Z>
schema:name <jami://$SENDER-ID/public/profile/name.txt> ;
schema:image <jami://$SENDER-ID/public/profile/img.jpg> ;
schema:inLanguage <jami://$SWARM-ID/public/profile/default-language.txt> ;
schema:maximumVirtualAttendeeCapacity 4 ;
schema:remainingAttendeeCapacity $CODE ;
schema:dateReceived "$RECEPIENT-DATERECEIVED"^^xsd:dateTime ;
schema:endDate "$RECEPIENT-DATERECEIVED+1H"^^xsd:dateTime .
}
}
où:
$RECIPIENT-ID est l’id du destinataire,$SENDER-ID est l’id de l’expéditeur,$SWARM-ID est l’id du swarm public,$CODE est le code de l’expéditeur,$RECEPIENT-DATERECEIVED est la date de réception du message,$RECEPIENT-DATERECEIVED+1H est la date réception du message plus 1h.
Les codes par défaut pourraient être:
- “3” : une table de 4 places dont 3 sont disponibles,
- “2” : une table de 4 places dont 2 sont disponibles,
- “1” : une table de 4 places dont 1 sont disponibles,
- “0” : une table de 4 places dont 0 sont disponibles, ce qui signifie aussi “effacer la table de la base de données” puisqu’il est a priori inutile de conserver dans la base des tables pleines ou des tables vides (personne à qui parler).
D’autres codes pourraient être utilisés, mais certaines propriétés des tables devraient plutôt être déterminées par les propriétés des cafés (swarm), et non exprimées par des codes complexes.
Un seul octet suffit à encoder 256 types de table, ce qui est déjà considérable.
La propriété la plus important d’un swarm café est sans doute la langue.
Ainsi, en envoyant un code de table sur le swarm café d’une langue, la langue par défaut de la table est automatiquement déterminée.
Si les cafés deviennent populaires et trop grands, rien n’empêche de créer de nouveaux cafés, qui ne sont rien d’autres que des swarms dans lesquels on s’échange des codes de table, et d’ajouter d’autres propriétés, comme des noms propres aux cafés, ou des sujets de prédilection (propriété: foaf:topic).
La table de l’hôte: un swarm privé
La vie classique d’une table de café est:
- création d’une requête SPARQL et enregistrement de la table de l’hôte dans sa propre base de données,
- envoi d’un code de table sur le swarm café approprié (notamment la langue),
- réception et conversion par les destinataires du code de table en requête SPARQL sur la base des modèles pré-enregistrés, et enregistrement de la table dans la base de donnée du destinataire (nota: plusieurs tables peuvent être enregistrées à travers une même requête),
- affichage des cafés et des tables dans l’interface Jami des hôtes et des destinataires,
- connexion de destinataires à un café puis à une table,
- des codes de mise à jour de la table sont envoyés automatiquement par l’hôte au café, afin de renseigner au swarm café le nombre de places disponibles à sa table,
- si la table n’est pas mise à jour dans le café au bout d’une heure ou si l’hôte envoie le code “0” au café, la table est supprimée, c’est-à-dire que les pairs du swarm ont une routine qui nettoie automatiquement les tables vides ou pleines du café.
Bases de données RDF pour reconnexion des paires après déconnexion de l’hôte
Les Bases de données RDF, dites triplestores, sont très utiles pour stocker et partager des métadonnées.
Une métadonnée très utile à partager à une table serait la liste ordonnée des id des hôtes secondaires (sous forme d’IRIs), ce qui permet aux participants de se reconnecter immédiatement en cas de déconnexion de l’hôte principal.
Sécurité
Les swarm cafés ont une politique de sécurité un peu différente des swarms traditionnels.
Ils n’échangent que des codes de tables.
Ces codes ne sont pas destinés à des êtres humains, mais à des programmes.
Par ailleurs, les pairs peuvent être connectés à des toiles de confiance, afin d’accepter ou de rejeter les connexions et les codes dans les swarm cafés.
Les toiles de confiance permettraient de signaler aux autres les pairs qui flood le swarm café, envoient des codes faux ou erronés ou qui ont un comportement non-humain aux tables (connexions extrêmement courtes, connexions simultanées ou successives à un très grand nombre de tables par unité de temps, connexion audio sans envoi de son, etc.)
Ainsi, les cafés pourraient s’autoréguler sans besoin d’un point de contrôle central.
Il peut exister des swarm cafés publiques (ouverts et sans administrateur) semi-publiques (ouverts et avec un administrateur) ou privés (fermés).
mais c’est là que vous nous (