Discoverability of root and controllers of Pods - some thoughts

[megoth]

This is probably a bit too early in the process, but wanted to share some thoughts for a couple of data points that we've had to assume in the current data browser (as the current spec doesn't help us).

I've written up the thoughts on https://megoth.inrupt.net/public/SolidDataBrowser/pod-info.html. If you use dokieli to annotate, please let me know, so I can add you to my WebID as foaf:knows (which should enable me to see your annotations).

I would hope that we can standardize some mechanism that allows for discoverability of storage for a given resource. I also think discoverability of controllers are useful, but I understand that there are tougher questions to deal with on that one.

[RubenVerborgh]

(Sorry, pressed the wrong button.)

[RubenVerborgh]

I don't think "root of pod" should be a thing; I don't think the concept of "pod" has a place in the data model. It's only resources and folders.

[megoth]

I don't think "root of pod" should be a thing; I don't think the concept of "pod" has a place in the data model. It's only resources and folders.

If all of these instances are replaced with storage, does that make it better?

The goal is to have some way of knowing what the storage for a given resource is without assuming anything about the setup for the given Pod.

[RubenVerborgh]

If all of these instances are replaced with storage, does that make it better?

Probably, yes.

The goal is to have some way of knowing what the storage for a given resource is

Or in the solution-oriented (which is not always good) terminology I currently have in mind: what shape it conforms to. So then the resource would be part of a folder, which would conform to a shape structure, recursively.

[megoth]

The goal is to have some way of knowing what the storage for a given resource is

Or in the solution-oriented (which is not always good) terminology I currently have in mind: what shape it conforms to. So then the resource would be part of a folder, which would conform to a shape structure, recursively.

I agree that shapes are important for resources, but that doesn't solve the question of which storage a resource belongs to, I think? Just asking in case I have missed something wrt shapes.

[RubenVerborgh]

doesn't solve the question of which storage a resource belongs to, I think?

I don't think that question really has an answer though. A resource might be associated with zero, one, or multiple storages.

[megoth]

doesn't solve the question of which storage a resource belongs to, I think?

I don't think that question really has an answer though. A resource might be associated with zero, one, or multiple storages.

True, but in the cases where straightforward answers exist, why not serve them? I understand that there are complex cases around this, but I think these data points are useful to clients such as data browsers to offer context.

[RubenVerborgh]

True, but in the cases where straightforward answers exist, why not serve them?

Name one 🙂

I randomly picked https://drive.verborgh.org/public/icon-decentralization-markets.png, but feel free to pick any other example. What is the storage of this resource?

[megoth]

True, but in the cases where straightforward answers exist, why not serve them?

Name one 🙂

I randomly picked https://drive.verborgh.org/public/icon-decentralization-markets.png, but feel free to pick any other example. What is the storage of this resource?

I would guess https://drive.verborgh.org/ is the storage of this resource.

[RubenVerborgh]

I would guess drive.verborgh.org is the storage of this resource.

Possibly. Could also be https://drive.verborgh.org/public/.
They are not really distinguishable from an external point of view.

The point I was trying to make is that the straightforward cases are probably the exceptions rather than the other way round.

[megoth]

I would guess drive.verborgh.org is the storage of this resource.

Possibly. Could also be https://drive.verborgh.org/public/.
They are not really distinguishable from an external point of view.

Exactly, but only one of them is the root of the Pod.

Now, perhaps this is a good time to ask why shouldn't the root of the Pod be a thing in the data model? (I should've asked that in the beginning.)

The point I was trying to make is that the straightforward cases are probably the exceptions rather than the other way round.

I understand, and it might be that this is too expensive for too little value. But in the current data browser I think it gives value, so I would like us to explore the possibility of having something like a pointer to the root of the Pod standardized.

[RubenVerborgh]

Exactly, but only one of them is the root of the Pod.

You don't know that actually. I can perfectly declare https://drive.verborgh.org/public/ to be the root of the pod, and the contrary cannot be proven.

Now, perhaps this is a good time to ask why shouldn't the root of the Pod be a thing in the data model?

As much as I dislike turning the tables as an argument, I need to here 🙂 Solid is just LDP, and LDP does not define any special root concept. So the question is: does Solid need such a root concept, and why?

So far, we have not had that need. My profile points to a location apps can write to. That might or might not be a (root) pod. It's just a folder and it behaves the same as all other folders. The root has no interesting observable behavior that makes it different.

having something like a pointer to the root of the Pod standardized.

But what is the use case? Like, on a high level?

Knowing that there's no 1-to-1 user to pod mapping, i.e., there's just WebIDs with access to folders.