Enabling open-with?

[jg10-mastodon-social]

This may be out of scope -

For software applications a possible use case of catalog data is to 1) identify whether the application supports opening a resource, 2) provide information about how a catalog consumer would open a resource in the given application.

(1) Is fairly complex and deserves its own issue, but (2) may be relatively easy to support, building on the observation that ex:webAppEndpoint already seems to support linking to the landing page of the app itself.

The Solid App Launchers STM on 18 March discussed the proposal:

Add a interop:hasDisplayEndpoint predicate to interop:Application. This is an URL where the user will be redirected when they want to display a resource with the given application. It takes a resource query param with the resource URI. The application will be responsible to redirect the user to the correct page within the application.

To maximise compatibility with existing apps, I would prefer to be able to customise the query param used to indicate the resource URI to open, e.g.,

:PantryApp a interop:Application;
    interop:hasDisplayEndpoint <https://pantryapp.example.com>;
    ex:resourceIndication "uri".

Including this information in the catalog would allow pod management apps to suggest apps that could be registered to open resources.

Until (1) is also solved, the registration process would be implementation specific, but this already seems like it could be a big win in helping pod management apps drive utilisation of external apps.

@elf-pavlik and @srosset81 may have an opinion based on the STM discussion?

[elf-pavlik]

Thank you for bringing it up @jg10-mastodon-social
Current shapes already have ex:clientId where specific app endpoints should be discoverable.
As for finding which app can open what kind of data (a.k.a. access scopes) I had very rough placeholder in https://elf-pavlik.github.io/solid-efforts/#/?tab=scopes I would definitely see that information useful in the catalog.

To be honest your suggestion for ex:resourceIndication should be tracked in another venue, it seems like someone didn't do their homework after STM to set up space to continue this exploration 😳

I put to much on my plate but that isn't an excuse, I just need to get my act together and get better at 🤹‍♂️

[jeff-zucker]

In addition to clientID, applications can use what we are temporarily calling webAppEndpoint to point to a web-accessible version of a software.

We are in discussion about the "what can a thing access". We need to think through what the object of the triple is - an rdf:Class? a shape? a domain of knowledge?

Currently we are using keywords to see what sorts of things people add. In the next version of the catalog we will formalize the keywords, including, perhaps defining additional predicates to capture the relationship between a Product and other kinds of resources.

[jg10-mastodon-social]

Thanks for the replies!

In addition to clientID, applications can use what we are temporarily calling webAppEndpoint to point to a web-accessible version of a software.

Both of these are close but don't quite fit the use case I'm trying to describe.

As another way of describing it, I want to be able to know which apps have the ability to open e.g.
https://my.pod/resource by navigating e.g. to https://pantryapp.example.com?uri=https://my.pod/resource
(And I also need to know that I have to use uri= and not resource=)

For client IDs:

• A client id may or may not include description of how to display a resource.
• Even if it did, a pod management app would need to dereference all the clientIds to determine which apps have the ability to be passed a resource.
• An app may also be able to display a resource without having a client id

For webAppEndpoint, my understanding is that this is just the landing page. Many apps don't allow deep linking to a specific resource and instead the user needs to navigate to it manually.

Nevertheless, the following would solve the use case for most apps:

:PantryApp a ex:Product;
    ex:webAppEndpoint <https://pantryapp.example.com>;
    ex:resourceIndication "uri".

The main downside is that it assumes that the URL to open a given resource is the same as the web app's landing page, which is not necessarily the case.

To be honest your suggestion for ex:resourceIndication should be tracked in another venue, it seems like someone didn't do their homework after STM to set up space to continue this exploration

No worries! I know you're busy, and I also see that other parts of the interop vocab edits are progressing.

I decided to raise this here because it's anyway not an SAI-only issue. There's nothing stopping us from having two different mechanisms for indicating how an app opens resources - one in a catalog context (if it's within scope), and one in an authorization agent context.

Edit:
For completeness I've also previously experimented with a predicate:

apps:uriPrefix "https://pantryapp.example.com?uri="

People seem to prefer separating out the query param.

[jeff-zucker]

I didn't mean to imply that the existing predicates solve the problem you are raising. I think it's an important problem. So suppose we have a predicate like ex:accesses and we have triples like ex:AppX ex:accesses ex:ThingY. What is ThingY? Is it an rdf:Class so we can say accesses vcard:AddressBook? Or as shape so we can say accesses solidContacts:PersonShape? Or something in the real world like accesses PatientHealthCareData?

Also, please look at #2 which explores other aspects related to this issue.