Store every LDP resource in its own named graph

[srosset81]

Until now, SemApps has always created LDP resources "on the fly" by looking at triples with the corresponding subject. This created limitation, since these resources could not include triples that were not directly related to the resource. To be Solid compliant, we need to store every RDF document in its own named graph. This was not possible as long as we kept the Fuseki WAC dependency, but it will be possible with Fuseki (without WAC extension) and with NextGraph.

• Create new DocumentService
  • This will be called by the ldp.resource.create action.
  • Create action:
    • For Fuseki: since named graphs don't need to be explicitely created, simply return a generated UUID
      • Niko said we could also use NextGraph to generate UUID, to ease then transition to NextGraph. But this would require to keep a "blob" of the document, to be used when we really want to create the NextGraph document.
    • For NextGraph: on create, call NextGraph API and return the UUID that is generated. We will also need to pass the HTTPS URI to NextGraph API when creating the document (see this comment).
• Refactor LdpService
  • GET: The slug is the UUID of the NextGraph document
  • POST: We call the DocumentService, which returns a UUID. We then use this UUID as the resource slug.
• Refactor MirrorService
  • The MirrorService use a custom named graph to store mirrored data. We did this because, in the idea of the MirrorService, all data were public so did not need ACL checks. The WAC extension did not check permissions on this graph.
  • If we stop using this WAC extension, we can store these mirrored resources as any other resources, that is, in their own named graph.
  • Since the URIs of mirrored resources is that of an external server, we cannot use a did: URI for them. So we will keep the full URI. If they are attached to a LDP container, we will use the document DID as a predicate (like any other LDP resource), and then return the resource starting with https://
• Migrate all existing resources
  • NextGraph UUIDs are cryptographic keys. This means the UUIDs generated by SemApps are not compatible. All URIs will need to be re-generated.
  • The migration will thus be different if the new triplestore is Fuseki or NextGraph:
    • For Fuseki, we need to go through all the resources, move them to their own named graph with the same https:// URI.
    • For NextGraph, we will need to create a document for each LDP resource (with the DocumentService), rename the resource with returned UUID and store it on this new document. Then we must go through the triplestore and rename all references.
    • All links after a NextGraph will be broken. We could set redirects, but for ActivityPods, since we don't have so many Pod providers for now, we will probably just ensure that all cached informations are deleted.

Notes regarding NextGraph:

• Unlike Fuseki, NextGraph requires named graphs to be created explicitely.
• When created, a named graph includes some initial triples (?)
• The named graph name will be the UUID (starting with did:ng:)
• In NextGraph triple store, the LDP resources URIs will also start with did:ng:. It will be up to the TripleStoreService (or LdpService ?) to convert them to https:// URIs.
• To be compatible with future NextGraph apps, it is better if the URI of the resource is the same as the URI of the named graph.
• By default, the triplestore is configured to do a "UNION GRAPH", which means it will look for all data on all graph. We can of course look for a single graph with the appropriate query.
• NextGraph offer features for caching, that are similar to the MirrorService, but which use a different mechanism. We will see in the future if we can take advantage of that.

[simonLouvet]

I agree, but how can we apply WAC rules using the sparql endpoint of semapps middleware?

[srosset81]

It won't be possible anymore, unless someone improve the Fuseki WAC extension in such a way that named graphs are persisted (Niko said it was possible, but he doesn't have time for this).