Ambiguity around the Type Registry

[JordanShurmer]

First of all, I'm not entirely sure this is the right repo to create this Issue in. It is in regards to the Type Index concepts laid out in the data-discovery proposal.

The Issue

There is some uncertainty around the management of the Type Index Registry. As apps are interacting with the Type Index Registry are they expected to ensure it's in a good state in regards to the Types that it cares about?

• Are Solid apps expected to create the Index entry as well as the actual location if either one is missing?

  • What if the Index entry doesn't exist, but the location the app would like to create does?
  • What if the Index entry exists, but the location it points to does not?
  • etc.

• Another option would for apps to prompt the user for the desired location.

• Or, perhaps apps should just inform the user that they don't have a valid location for that type and leave it to the user to add via their POD

[JordanShurmer]

Relevant Remarks from Gitter

We actually ran into a similar problem with notifications though, albeit slightly differently. There’s some cases where the global inbox isn’t available, whether by design or not, meaning it’s impossible to send global notifications to a user. For now, we’re showing an error and catching that case, and linking to a dokieli document explaining how the user can create their own inbox. We determined we didn’t want the SDK app to be in charge of fixing thte issue, because it’s possible the structure or spec could change and then every SDK app would need to be updated (and that makes no sense / is bad practice)

— James Martin

---

@JordanShurmer : If a user doesn't have an entry for the type that an app cares about, what's the expected action? Should the app make up it's own location and add it, or should it prompt the user in some way to choose a location? What do people think would be a good practice.

@timbl : Good question. It depends a bit on the application — is this the sort of thing a typical user will have one of, like address book, bookmark list, or the sort of thing a user will have many of over time like meeting, project, chat?
And users may vary as to how much control they want.
For the first kind, I think letting the user know where it is but then create it automatically. But be very careful not to create a new empty one which deletes an existing one. Make sure the file really isn’t there you get 404 back, it isn’t some other read error parse error or network error which made you think there was none!

@JordanShurmer : Well, this is actually in the context of making a Vue plugin - not the actual application. Should the plugin make it easy to write apps that auto-create, or apps that prompt for location? Or both, I suppose. seems like both approaches could be valuable. I'll do some thinking.

@timbl: Both I think. When it is called from inside the creation bar of say the folder view or a meetulator meeting then the base url is known already although the user may give the last bit, the short name.

— Jordan Shurmer and Tim Berners-Lee