Solid, documents et triple store

Je créé ce fil pour discuter des documents dans un contexte Solid.

Le document est un des fondements de HTTP et permet de faire des déclarations à propos de chose(s) dans un contexte donné. Techniquement, au sens de Solid, il permet de faire des paquets de triplets RDF, ou de regrouper des triplets (chose composé de 3 composants).

La spec WebID montre un exemple de ce besoin et particulièrement la section 3. The WebID HTTP URI : « When using URIs, it is possible to identify both a thing (which may exist outside of the Web) and a Web document describing the thing. For example, the person Bob is described on his homepage. Alice may not like the look of the homepage, but may want to link to the person Bob. Therefore, two URIs are needed, one for Alice and one for the homepage or a RDF document describing Alice. »

La section 4. Overview de WebID montre un schéma du lien entre le document et la chose représentée (Tim B. Lee en l’occurrence).

Sur le web et sur un POD on doit pouvoir exprimer plusieurs versions d’une réalité. On doit pouvoir exprimer différents points de vue. On doit pouvoir dire des choses contradictoires à propos de soi ou de n’importe quoi. Sur un POD je dois pouvoir me présenter plus ou moins agé par exemple :

Le document accessible à l’URL https://example.org/monPOD/jeune (turtle) :

<https://example.org/monPOD/profile#moi> ex:age "18"^^xsd:integer.

Doit pouvoir donner une version différente de mon âge déclaré dans le document https://example.org/monPOD/moinsJeune (turtle) :

<https://example.org/monPOD/profile#moi> ex:age "54"^^xsd:integer.

Dans les deux documents on parle bien du même sujet (https://example.org/monPOD/profile#moi).

Un POD doit également me permettre de contextualiser des déclarations identiques mais qui n’ont pas la même valeur. Par exemple, pour reprendre l’exemple de Henry Story, je peux avoir un document de mon médecin et un de mon barman me disant tous les deux de prendre de l’apirine mais cela n’aura pas la même valeur.

Le document du médecin https://example.org/monPOD/medecin (turtle) :

<https://example.org/monPOD/profile#moi> ex:doitPrendre <https://www.wikidata.org/wiki/Q18216>.

Peut contenir des triplets identiques à celui de mon barman https://example.org/monPOD/barman (turtle) :

<https://example.org/monPOD/profile#moi> ex:doitPrendre <https://www.wikidata.org/wiki/Q18216>.

La structure sous-jacente du POD doit permettre de différencier les informations afin d’afficher les bonnes en fonction du contexte demandé (l’URL du document).

Avec un triple store les triplets RDF ne sont pas contextualisés. Si on prend les exemples précédents, le triple store va contenir (turtle) :

<https://example.org/monPOD/profile#moi> ex:age "18"^^xsd:integer.
<https://example.org/monPOD/profile#moi> ex:age "54"^^xsd:integer.
<https://example.org/monPOD/profile#moi> ex:doitPrendre <https://www.wikidata.org/wiki/Q18216>.

Comment différencier les deux versions de mon âge ? Qui m’a dit de prendre des médicaments ?

C’est pourquoi Tim B. Lee et Henry Story expliquent qu’il faut un quad store, c’est à dire un triple store capable de stocker un 4 élément : le graphe (ou document ou named graph) auquel appartient le triplet.

Le store ressemblerait donc à (TriG) :

https://example.org/monPOD/jeune {
  <https://example.org/monPOD/profile#moi> ex:age "18"^^xsd:integer
}

https://example.org/monPOD/moinsJeune {
  <https://example.org/monPOD/profile#moi> ex:age "54"^^xsd:integer
}

https://example.org/monPOD/medecin {
  <https://example.org/monPOD/profile#moi> ex:doitPrendre <https://www.wikidata.org/wiki/Q18216>
}

https://example.org/monPOD/barman {
  <https://example.org/monPOD/profile#moi> ex:doitPrendre <https://www.wikidata.org/wiki/Q18216>
}
1 « J'aime »

Merci pour cette vulgarisation entre document et triplestore. Je suppose que tu le sais déjà mais jena gère les graph nommés qui pourrait nous permettre de faire de même (avec le dev adéquat) qui me semble être un quadstore.

J’ai par contre beaucoup de mal à embrasser la logique proposée par Tim B. Lee et Henry Story. J’ai vraiment l’impression que cette notion de contexte serait bien plus pertinente si elle se traduisait par des triplets.

Le Médecin → Prescrit → une ordonnance
une ordonnance → concerne → me
une ordonnance → contient → aspririne
Le barman → donne → un conseil
un conseil → concerne → me
un conseil → recommande → aspririne

Pour héberger ces triplets dans le pod du user, il faudra sans doute inverser le prédicat
me → est concerné par → une ordonnance
me-> est concerné par → un conseil

L’ordonnance et le conseil peuvent être stocké sur le pod du user ou un autre data-space.

Le fait que le « contexte » dépende d’un path ne donne aucune information sur ce que veut dire et ce sera à l’application de réagir en fonction du path ou du nom du fichier. Avec des triplets, toutes applications pourront beaucoup plus facilement proposer les bonnes fonctionnalités et affichage à l’usager

Je garde la sensation que l’architecture document nous encourage à s’accrocher à des branches mortes. Le contexte (l’interprétation) qui dépend du path n’a rien à voir avec rdf c’est un héritage qui dépend d’une arborescence de fichier et qui pour moi pollue les avancées dans le monde du web sémantique.

Je suis ouvert à tout argumentaire pour défendre l’architecture document et je passe peut-être à côté d’un truc essentiel (comme le genre de chose que tu viens de vulgariser @lecoqlibre ) mais pour le moment, je n’ai rien vu de tel.

1 « J'aime »

Quelques réactions rapides suite au post de Simon, mais je vais continuer à réfléchir à ce sujet…

Malheureusement non car le seul moyen que les graphs nommés soient persistés dans Jena Fuseki, c’est de les encoder en dur. Peut-être qu’une version plus récente de Fuseki supporte des graphs crées à la volée (?), mais ça impliquerait peut-être de mettre à jour notre extension pour les permissions WAC.

Très d’accord avec ça !!

Je comprends bien la logique des documents, et ton message @lecoqlibre est on ne peut plus clair. Mais comme Simon, j’ai encore beaucoup de peine à voir ce que ça apporte, le pourquoi plutôt que le comment. Dans ton exemple sur l’âge, à quoi est-ce que ça sert d’avoir des informations contradictoires, surtout pour un sujet comme l’âge où il y en a forcément une qui est vraie, et une autre qui est fausse ? Et si les informations ne sont pas contradictoires, alors elles vont s’additionner et c’est tant mieux.

Mais c’est une réponse à chaud, je vais continuer à y réfléchir…

1 « J'aime »

C’est pour ça que je précisais « avec le dev adéquat ». Je maitrise mal l’ampleur du dev coté Jena mais les fondations de jena / fuseki le permettent où le permettrons avec du budget/temps/humain à définir.

D’autre part Jena est pour moi limité pour les usages que nous avons à Data Players sur des gros volume de triplets. Je chercherai donc plutôt à coopérer avec oxygraph atteindre du quadstore WAC que améliorer Jena

1 « J'aime »

Dans ton exemple avec les recommandations on n’est plus sur des vocabulaires similaires. Le problème du contexte est juste décalé : comment faire si le médecin me fait la même recommendation que le barman ? Pour reformuler la question : comment gérer le fait que des choses identiques peuvent être déclarées (avec les mêmes ontologies) dans des contextes différents.

On simplifie un peu là mais en fait le contexte n’est pas lié à des paths directement mais à des documents définis dans un ou plusieurs standard(s) client à client. Une application saura comment gérer le contexte par son respect des standards client à client concernés.

RDF n’a rien à faire du web c’est vrai, on peut faire du RDF sans le web. Par contre le Linked Data c’est du RDF avec du web. Les documents font partie du web depuis sa création.

Cette question du pourquoi est très importante. On en a besoin car c’est ce qu’on fait dans la vie, tout simplement :slight_smile: Parce qu’on a le droit de se tromper, de dire des bêtises, d’imiter, de changer d’avis et puis de mentir parfois aussi.

C’est ce que dit Henry Story, si on n’a pas de documents, on se retrouve en présence d’une base de faits qui sont présentés comme cohérents. Or ils ne le sont pas.

Je n’ai pas joué avec les graphes nommés dans Fuseki. Fuseki est un quadstore donc à priori j’imagine qu’on devrait pouvoir créer des graphes nommés à la volée directement avec SPARQL. Ce serait étonnant qu’ils ne soient pas persistés mais je n’ai pas essayé.

1 « J'aime »

en précisant dans l’action (faire une recommandation) qui la fait, avec des triplets. chaque recommandation a son id. Je ne voie pas le problème.

1 « J'aime »

oui mais LDP n’est pas dépendant de l’architecture document, uniquement du web sémantique (rdf, owl …), http et de la notion de container. C’est justement, pour moi, la libération de la contrainte des documents.

1 « J'aime »

Pour le dire autrement : comment faire pour parler d’une même chose (un même sujet – un même sujet RDF) de plusieurs manières différentes ? C’est plus clair ?

1 « J'aime »

Pour moi, une part essentielle de l’architecture « Linked Data » est que l’identité d’une ressource est son URI. Et donc si on veut avoir des informations sur cette ressource, il suffit que je fasse un GET sur son URI (dans la mesure de mes permissions sur cette ressource)

Donc si je veux des informations sur Simon, je vais naturellement aller sur https://data.virtual-assembly.org/users/simon.louvet.pro Peut-être qu’une ressource localisée dans https://mypod.store/bob/data/mon-dossier/fichier.ttl affirmera que Simon s’appelle en réalité Pierre (<https://data.virtual-assembly.org/users/simon.louvet.pro> <https://www.w3.org/ns/activitystreams#name> "Pierre"), mais je ne vois pas pourquoi je devrais lui accorder du crédit ?

Maintenant, cette architecture n’empêche pas que Simon puisse avoir plusieurs profils, un où il affirme s’appeler Pierre, et un autre où il s’appelle Simon. Et qu’il puisse montrer tel ou tel profil selon ses interlocuteurs. Cette possibilité fut à la base du web (au grand dam de nos gouvernements), et d’ailleurs dans ActivityPods je compte bien la mettre en avant.

1 « J'aime »

Je me souviens que dans la toute la première réunion lors du reboot de SemApps (on était chez Guillaume en banlieue parisienne !), on avait parlé de ce problème de différencier le document de la « chose » qu’il désigne, comme c’est très bien expliqué sur cette image de la spec WebID:

Mais on s’est dit que s’il fallait faire cela pour toutes les ressources « réelles » (les organisations, les événements, etc), ce serait une énorme prise de tête qui n’apporterait pas grand chose. Et au final il n’y a que la spec WebID qui insiste sur cette différenciation – à mon connaissance, ça n’est repris par aucun autre standard ! La classe foaf:PersonalProfileDocument est d’ailleurs assez unique dans son genre.

Ma théorie personnelle pour expliquer ce fait est que le standard WebID a été écrit en 2005, et que depuis la communauté des développeurs a réalisé que c’était beau en théorie, mais compliqué en pratique. Mais comme le standard WebID (pourtant très simple) est à la base de beaucoup d’autres standards, personne n’a osé y touché (tout comme personne n’a mis à jour l’ontologie FOAF depuis 2004, qui inclus toujours des trucs comiques comme foaf:icqChatID)

Après ça ne serait pas un gros effort, pour être compatible Solid, de créer une ressource de type foaf:PersonalProfileDocument (sur sa propre URI) et de la lier au WebID. En tout cas rien dans la spec WebID n’oblige à ce qu’on utilise un URI avec un hash de type #me. Un URI normal marche très bien.

Concernant WebID, je suis intrigué par le fait la version spécifique à Solid (work in progress) ne fait pas référence à la différenciation WebID / Profile Document, pas même dans la terminologie. La classe foaf:PersonalProfileDocument n’est jamais mentionnée.

Résultat de quelques recherches: des gars de Solid essaient d’amener WebID à devenir une recommendation officielle, en créant un superspec qui engloberait l’ancienne et ajouterait une référence à JSON-LD, sans amener de breaking changes puisqu’elle est trop utilisée:

Pour le moment ça donne ça:

https://jacoscaz.com/WebID/superspec/webid.html

Dans cette superspec, l’Identity Document est toujours présent. Cette petite phrase nous concerne si on veut être dans les clous:

For WebIDs without fragment identifiers, an HTTP request on the WebID MUST return the status code 303 See Other with a Location header URI referring to the Identity Document.

Donc pas très compliqué à implémenter, même si franchement je vois pas trop l’intérêt de cet Identity Document, qui ne comprendra rien si ce n’est un lien vers le WebID :rofl: J’ai créé une issue.

1 « J'aime »

Si plusieurs fichiers expriment différentes réalités, cela n’a d’intérêt que si nous connaissons le contexte de cette réalité :(une application dit que…, une organisation dit que … , une personne dit que …, un agent dit que…).

Si ces différents contextes sont au sein du même serveur, le chemin du fichier n’exprime pas ce qu’est ce contexte et il faut ajouter des prédicats (relations réifiées par exemple) et/ou des sujets pour exprimer ce contexte.

Si une même personne veut créer plusieurs versions de la réalité sur un sujet, il est totalement possible de le matérialiser par des versionnements de sujet.
sujet → version → maVersion1DuSujet
maVersion1DuSujet → desription → ma première description
sujet → version → maVersion2DuSujet
maVersion2DuSujet → desription → ma deuxième description

Je peux transmettre l’uri de maVersion1DuSujet ou maVersion2DuSujet avec des droits ACL différents en fonction de l’interlocuteur.

Si ces différents contextes dépendent du serveur/pod/data space sur lequel est accessible l’information, le contexte est explicite dans l’uri et compatible LDP sans avoir besoin d’une architecture fichier/document.

Je vois toujours des inconvénients à l’architecture document et le besoin fonctionnel peut être mieux satisfait par une architecture triplestore. Le seul avantage que je vois à l’architecture document est la sobriété technique, mais c’est pour moi au prix de compromis/simplifications/incohérences.

1 « J'aime »