TypeIndex support

[srosset81]

https://github.com/solid/type-indexes

This is a recommended Solid way to identify containers based on the class they contain. This could be used in Pod provider config to replace the VOID endpoint.

Implementation

• Automatically create a TypeIndex in /solid/type-index
  • Public TypeIndex for containers with public read rights
  • Private TypeIndex for other containers
• Link it to WebID with solid:publicTypeIndex and solid:privateTypeIndex
• In the data provider, for pod provider config, read this file instead of the VOID endpoint to find about the available containers.

Example

@prefix solid: <http://www.w3.org/ns/solid/terms#>.

<>
    a solid:TypeIndex ;
    a solid:ListedDocument.

<#ab09fd> a solid:TypeRegistration;
    solid:forClass as:Event;
    solid:instance </as/events>.

Issues

• Can we put all this on the same JDON-LD document, or if do we create a resource for every TypeRegistration ?
  • See Missing predicate between solid:TypeIndex and solid:TypeRegistration solid/type-indexes#29
  • Once we support hash URIs, this could be possible

[NoelDeMartin]

Hey, I was going through the spec compliance page for Solid, and I was happy to see that you already support most of the features my apps rely on :D. In particular, there's something I wanted to mention about type indexes. You may already be aware of it, but I thought I'd mention it here just in case.

Type indexes are supposed to be a "client-client" standard; which means servers (ActivityPods in this case) don't even need to know about it. You shouldn't have to do anything special for them to work, if everything else is conforming with the Solid spec. Though of course, there is nothing wrong with creating it for your users automatically. But keep in mind that some people don't want to list everything in their type index, so I'd be wary of automating too much on the server side.

In my experience working with Type Indexes in different PODs, the only pain point I've found is that profiles sometimes are read-only. My apps create the type index when it doesn't exist, but in order to declare the type index I need to update the profile document. So if that isn't possible, I can't mint the type indexes.

The whole topic of whether profiles should be read-only or not is also under discussion, but if the type indexes are minted by the server that shouldn't be a problem.

[Laurin-W]

Hey Noel, thanks for spelling this out! I'm not an expert here so I might not grasp the whole picture.

But keep in mind that some people don't want to list everything in their type index, so I'd be wary of automating too much on the server side

What are cases where a person does not want to list everything in their type index? To hide the existence of certain objects?

[NoelDeMartin]

I recently spoke with @josephguillaume about this, so maybe he can better explain it. But my understanding is that the main goal of a Type Index is not to list the objects from one POD, but to make lists of collections. This means, for example, that a type index could also point to objects from different PODs, not just your own.

Although I will say that in my apps I am totally registering everything xD (in the private type index though, nothing in the public one by default). The point, though, is that since Type Indexes are handled in the client, different apps may use them differently. If the type index spec is ever finalized, and it's clear how they should work, maybe it would be useful for servers to create them as well. But as things stand right now, I think the only thing a server should do is creating the type index documents if they want. But I'd be wary of registering anything.

Also, because it may not be obvious what to register to begin with. For example, if I have recipes, are you going to register the container as an instanceContainer? or each recipe as an instance? And would you do it on the public type index, or the private one? etc. I think there are too many open questions at the moment to make any assumptions from the server side.

[josephguillaume]

What are cases where a person does not want to list everything in their type index?

I'd recommend this PR for some of the vision behind the type index, as well as some discussion.
solid/type-indexes#26

As Noel described, the idea is to point to specific containers/documents where new instances can be added and existing instances in a collection can be found. A collection can be added to, filtered and curated over time. A pod can receive instances from outside, e.g. from emails, RSS feeds, or shared directly from another pod. An instance shouldn't automatically be added to a curated collection - the collection defines a boundary that the user needs to have control over in some way. Similarly, one might want multiple several collections. Events for different contexts, different types of events, event collections that are shared with different people etc. The document-centric model specifically does not automatically pool all instances. https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/

A user can of course have a collection of all events in a pod if they want, though Solid currently doesn't standardise any specific approach to pagination.