Urls relatives au rootContainer à la place d'urls du serveur semapps stockées en dur dans Fuseki

[scenaristeur]

Décrivez le bug
Les ressources sont stockées avec l'url (localhost:3000) en dur dans Fuseki ce qui pourrait nuire à la portabilité du truc et semble hypothétiquement source d'erreur...
exemples :

• lancement depuis un autre port localhost:3001 -> plus rien ne correspond,
• accès à semapps depuis un autre nom de machine par résolution DNS -> les ressources seront enregistrées sous https://nom_de_machine/persons/... une machine peut avoir plusieurs noms

Comportement attendu
Avoir des urls relatives au rootContainer, ou/et des urls absolues incluant un nom de domaine pour garantir leur unicité.
exemple d'url relative dans un fichier .acl sur un pod Solid

@prefix : <#>.
@prefix n1: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix c0: </profile/card#>.

:owner
    a n1:Authorization;
    n1:accessTo <bidule.txt>;
    n1:agent c0:me;
    n1:mode n1:Control, n1:Read, n1:Write.
:public
    a n1:Authorization;
    n1:accessTo <bidule.txt>;
    n1:agentClass foaf:Agent;
    n1:mode n1:Read.

---> @prefix c0: </profile/card#>. correspond sur chaque pod à la ressource contenant le webid -> https://spoggy-test6.solidcommunity.net/profile/card#
---> n1:accessTo <bidule.txt>; correspond à la ressource bidule.txt dans le même container

[srosset81]

Je me trompe peut-être, mais il me semble que dans un triple store comme Fuseki, le principe est d'utiliser des URIs complètes partout. Après si c'est possible d'utiliser des URIs relatives, tant mieux, y a-t-il de la documentation dans ce sens ?

L'exemple de fichier turtle que tu montres, c'est plutôt une question de formattage. On pourrait afficher les données de cette manière sans pour autant changer les URIs stockés dans le triple store.

Lorsqu'une requête SPARQL est effectuée, il faudrait quand même pouvoir retourner les URIs complets (avec le nom de domaine), sinon les résultats sont inutilisables.

[srosset81]

Une idée @simonLouvet ?

[simonLouvet]

J'aurais pas dit mieux @srosset81

[scenaristeur]

le principe est d'utiliser des URIs complètes partout

totalement d'accord, je soumettais juste l'idée que si on y accède par le port 3001 au lieu de 3000 ou part un nom de domaine, les urls complètes risquent de ne plus être cohérentes les unes entre elles... ou il faudrait prévoir un système de migration.

[srosset81]

J'ai déjà eu à faire ce type de migration, une requête SPARQL avait suffit, mais je ne crois pas l'avoir sauvegardée. Peut-être qu'on pourrait proposer un service Moleculer pour faciliter ce type de migration, ou d'autres types d'opérations complexes. Par exemple une action migration.changeBaseUri avec comme paramètres oldUri et newUri.

Une idée sur d'autres besoins qu'il pourrait y avoir en terme de requêtes complexes ?

[simonLouvet]

++ pour un service de migration. Idéalement il pourrait être déclenché automatiquement lors d'un changement d'URL de base.

[srosset81]

OK j'ai créé une issue spécifique #561. Continuons la discussion là-bas.