Process for discovery of suitable apps for a resource

[josephguillaume]

I would like to confirm my understanding of use cases where a user receives a uri and wishes to check whether an app can open it, or identify an app to open it with.

My understanding is that the intention would be that the shape tree of the resource is identified, and then compared with the registered shape trees provided by application identity profile documents.

Following the spec, it appears there is no link from a data instance to its data registration. Is this correct?

Instead, this use case seems to be covered by the shape tree spec, with the link header providing the shape tree manager. If so, is there a link between the data registration and shape tree manager that needs to be specified? And would this link header be a should or a must? Will servers consistently provide it? (it's a must for shape trees)

As a point of comparison, I like the way I can: 1) dereference a resource 2) look up its rdf:type 3) check whether apps support that type

I understand the need to check shapes rather than just types, but my preferred option would be to replace step (2) with looking up the shape or shape tree expressed in a single triple rather than by checking headers or loading registries. I expect that might be too simplistic, but I don't yet understand why.

[elf-pavlik]

Hi @josephguillaume

Thank you for your feedback!

My understanding is that the intention would be that the shape tree of the resource is identified, and then compared with the registered shape trees provided by application identity profile documents.

From what I know there is no server-side support for shapetrees available (yet). @ericprud can correct me

• https://github.com/CommunitySolidServer/CommunitySolidServer/issues/639

I had a similar need lately and I ended up doing the following:

• start with IRI denoting the resource
• find the data registration, given that I always use flat containment in data registration, this will be the IRI until last '/'
• find data grant for that data registration, this assumes that we access a protected resource following our nose from the data grant
• get shape tree from the data grant

I have my initial code in this commit: https://github.com/elf-pavlik/sai-js/commit/323d49e50a0782046c6162da66425810bed101cf#diff-6ce17aac5f6ebf2f59677410f3993277eb8cd5ee5580002e9bb64cf5d54e650dR176

I'm not sure if that helps, but I'd like to follow up on this issue soon and look for improvement to the spec, which could make it easier. We should also look at server-side support for shape trees.

[josephguillaume]

Has the panel discussed the possibility of assigning a type to the container?

Suppose .meta includes <> a ex:MyShapedContainer

Dereferencing ex:MyShapedContainer could provide information about the applicable shape tree, but even without dereferencing, the client would already have just enough information out of band to perform basic reasoning before parsing the shape tree itself.

Clients can also identify the applicable shape of an arbitrary resource through similar inheritance logic to WAC - the applicable shape can first be checked against explicit shape assertions, then shape trees associated with the container, then shape trees of parent containers etc.

[elf-pavlik]

Suppose .meta includes <> a ex:MyShapedContainer

I will try to stay precise here since .meta is just an implementation detail. I understand that this statement would be one of the client-managed statements describing the container itself. And would be included in the representation returned on GET in the container.

Is this rdf type simply a class of the container itself, something like ex:PhotoAlbum, or does it imply something about the type of contained resources?

I will be able to understand it better if you share a few concrete snippets, preferably the actual data you are working with (anonymized, of course).

[josephguillaume]

The concrete example I've been thinking about is the Umai data structures https://github.com/NoelDeMartin/umai/issues/19

The rdf type is simply the class of the container itself, but through ontology or shapes/shape trees is intended to imply something about its properties, including types of its contained resources.

[elf-pavlik]

Thanks! I will read through that issue as soon as I can. Right away, I don't like the idea of needing for every ex:Something to define class ex:SomethingContainer. If you would like to have the container directly describe what type of resources it contains, I would rather define a dedicated property and reuse existing types of contained resources, for example, </foo/> solid:containsResourcesOfType ex:Something .

It duplicates some information that should be available via the shapetree and its shape, but I don't see a massive problem with duplication whenever it is justified. Anyway, I should read the whole original issue before commenting on it further.

[josephguillaume]

I've now also opened an issue to discuss a shape tree for Umai; https://github.com/NoelDeMartin/umai/issues/22

As shown there, Umai cookbook containers contain documents that each include four different shapes.

<cookbook/> ldp:constrainedBy <UmaiShape-v1.ttl>. would currently be the best fit if there is reason not to use <cookbook/> a ex:UmaiCookbook-v1.

[josephguillaume]

I came across https://github.com/shapetrees/specification/issues/38 which discusses discovery of shapetrees for a container through http vs container triples, e.g.,

<> a ldp:BasicContainer ;
   st:manager </data/CommonNotes/meta/UUID> .

The discussion is from 2021 and presumably superseded, though it doesn't seem to have a clear resolution.

Edit: On rereading, the intent of using Link header is clear, mainly driven by not messing with user data and improving performance of discovery of constraints on user data.

[josephguillaume]

I've been revisiting the SAI spec, and my current understanding is that the registry set, data registries and agent registry are by design only accessible by an application if it has received the a data grant for those registries. Is that correct?

Revisiting my original use case, emphasising the last part

where a user receives a uri and wishes to check whether an app can open it, or identify an app to open it with.

Discovery via either shape tree link header or the data registration require that the user has already received a data grant to the data or the data registry respectively.

1) If the app already has access to a data grant for the uri, then it probably can already open it itself and it didn't need to discover a different suitable app in the first place? 2) If every app needs to have access to the data registry for this use case, then it seems that SAI loses the advantage of keeping type indexes private 3) It seems the intended solution is via a privileged launcher app, i.e. for an arbitrary uri, individual apps should NOT be able to identify an app to open it based on the social agent's data. Instead, the individual app should send the uri to the launcher app to be handled.

Does this sound accurate?

[elf-pavlik]

It seems the intended solution is via a privileged launcher app, i.e. for an arbitrary uri, individual apps should NOT be able to identify an app to open it based on the social agent's data. Instead, the individual app should send the uri to the launcher app to be handled.

In many situations, the Authorization Agent is a natural fit to take on responsibilities that require complete trust. I think it could be similar to (or even incorporated into) sharing workflow based on resource indication: https://solid.github.io/data-interoperability-panel/primer/application.html#resource-indication