What is the domain of the solid:owner relation?

[kjetilk]

Following the discussion in #264 , it was left as an open issue what the domain of the new solid:owner relation should be.

Please see the comments in #264, and add to the discussion here.

[kjetilk]

My feeling here is that we have a good definition of a storage in the spec as of now:

Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage

This connects the URI path hierarchy to something that is specifically Solid, but the defintion of ws:Storage isn't that constrained:

A storage is a space of URIs in which you have access to data.

This may have very different organizations, it doesn't need to have the Solid URI path hierarchy. It could be sitting on somebody's disk with URNs...

Therefore, I feel it is very attractive to refine the definition to tie the URI path hierarchy directly to the definition of the RDFS class that we use for this.

Now, I realize it may too late to introduce a new class to denote something that has been in Solid for a looong time. Perhaps we could just handwave it, and say something to the effect that "In the context of Solid, we understand ws:Storage to mean the storage that be found by traversing the URI path hierarchy.

[timbl]

We use solid:owner to specify the owner of a pod. But there seems to be be reason to restrict it in the ontology to be as specific as a Storage. I'd like to be able to use it elsewhere internally for things like folders and files within the pod ... or bots for that matter maybe also.

Suggest remove the domain constraint on solid:owner

(Sorry I missed the discussion in the previous PR)

I may want in my code to do things like

{ ?doc pod: ?storage .    ?storage solid:owner ?x } => { ?doc solid:owner ?x }

OWTTE

[csarven]

solid:owner was based off acl:owner

The person or other agent which owns this.\n For example, the owner of a file in a filesystem.\n There is a sense of right to control. Typically defaults to the agent who craeted\n something but can be changed."

but we ended up restricting it to Storage. The whole domain inclusion didn't particularly feel right either (to me) although we ended up agreeing to include it in the PR.

If we omit the domain for solid:owner so that any type of resource can have an owner (implicit control), we are good to go (by also updating the definition). Proposal:

solid:owner
    a rdf:Property, owl:ObjectProperty ;
    dc:issued "2021-05-19"^^xsd:date ;
    rdfs:comment "The person or other agent that owns this resource; considered to have implicit control, rights and responsibilities."@en ;
    rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms#> ;
    rdfs:range foaf:Agent ;
    rdfs:label "owner"@en .

This whole exercise is essentially graduating acl:owner to solid:owner.

Worth bearing in mind that the definition of the term "owner" in the Protocol is in context of a Storage, which might be fine, but it would be a specific case of solid:owner (without a domain). If we want "storage owner" (or "pod owner") instead, we can use that term but probably don't need to. I suggest to keep it simple by updating (relaxing) the current definition to any resource.

The above doesn't require a change to the Protocol requirement for discovering a storage's owner or what the owner link relation on the Storage implies.

[justinwb]

I suggest to keep it simple by updating (relaxing) the current definition to any resource.

For clarity, are we only suggesting to relax the domain so the property can be used more freely outside of the protocol's definition? If so that's seems reasonable - 👍

If we were going to incorporate this notion of non-root resource ownership in the protocol spec (which I don't think we're saying) we'd need a bit more deliberation. A few immediate questions would be:

• When a non-root resource does not have a solid:owner assigned, is it considered to not have any owner, or instead is it owned by the solid:owner of the pod
• What is the relationship between the owner of the storage/pod, and the owner of a resource in that pod?
• Can only storage owners assign ownership to individual resources?
• If it is a container, does that mean that the contained resources are also owned?
• What is the impact to access control rule evaluation? For example, does the assigned owner of a non-root resource have implicit control access on it?

[gibsonf1]

I am confused how this would be usefully implemented on the server side if solid:owner can apply to any resource if that predicate is used outside the context of an acl:Authorization. If the idea is that solid:owner is used inside of an acl:Authorization where you can also in that same authorization use acl:default (thus giving an agent control of an entire pod by assigning solid:owner and acl:default assigned to / ) that would make sense. I've heard discussion elsewhere on how default can be applied separately, but I think the context of default has to be the other predicates within the same Authorization in which default resides

[TallTed]

Rather than dropping the rdfs:domain triple, I would change it, to solid:owner rdfs:domain rdfs:Resource, which is the current meaning implied by leaving the rdfs:domain out entirely.

By definition, such an explicit statement requires no inference, which people balk at too frequently, and this effective wildcard should prevent folks deciding that there's some restriction on the rdfs:domain when there isn't any.

[gibsonf1]

Wouldn't the domain of solid:owner be acl:Authorization?

[TallTed]

[@gibsonf1 said] Wouldn't the domain of solid:owner be acl:Authorization?

What makes you think that? It doesn't fit with the proposal from @csarven at all, nor, to my eyes, with anything else suggested or stated in this thread.

[csarven]

are we only suggesting to relax the domain so the property can be used more freely outside of the protocol's definition?

Vocabularies and specifications usually evolve independently. Irrespective to solid:owner having a domain or not, it wasn't limited to any specification. The Solid Protocol may only need to require solid:owner in the context of storage but the definition of the predicate need not be limited to storage.

If the Solid Protocol introduces the notion of any resource having an owner (re implicit control):

When a non-root resource does not have a solid:owner assigned, is it considered to not have any owner, or instead is it owned by the solid:owner of the pod What is the relationship between the owner of the storage/pod, and the owner of a resource in that pod?

Storage owners persist for all resources. Individual resources may have distinct owners.

Can only storage owners assign ownership to individual resources?

Since storage owner is tracked "in an implementation defined way", tracking the owners of any resource should be consistent with that.

If it is a container, does that mean that the contained resources are also owned?

Specs like the Protocol and WAC has a resource-centric view, so unless there are exceptions, to be consistent, it would be no. This shouldn't be conflated with discovering a storage's owner which happens to be on the root container / storage.

What is the impact to access control rule evaluation? For example, does the assigned owner of a non-root resource have implicit control access on it?

Same as any resource.

---

how this would be usefully implemented on the server side if solid:owner can apply to any resource

That is indeed an open question if that were to be defined in an interoperable way. Bear in mind that we approached "owner" in an implementation defined way so that storage control can't be uniformly changed across pods.

[gibsonf1]

@csarven How would you indicate ownership of a pod with solid:owner?

[csarven]

IMO, and certainly not suggesting any consensus here:

First, I don't think the notion of "pod" fits well in specs and I'd be in favour of removing it altogether. Pod has been a useful but somewhat of a vague concept - that's a good thing! - to get across outside spec-talk, and we should continue to use it. A pod doesn't have a URI or a collection of URIs - "significant" things or resources do have a URI - or even a fixed set of features or services that would necessarily constitute a pod. Besides just short of saying something that implements the Protocol and perhaps other specs. I suppose that's a pod‽ Then again, pod is not a whole lot different than "storage" in practice. Main difference is that storage is sufficiently well-defined, at least as per the Workspace ontology that we use. "Storage" and "server" covers things precisely (and sufficiently?).

So, for the moment, I'm going to use the word "storage" because that's grounded with other concepts that's in use in specs eg. URI space, ownership, containers, data, access control system.

How would you indicate ownership of a pod with solid:owner?

• The storage resource (the root container of a URI space) can advertise the owner relation in the Link header.

• An RDF statement whose subject is a storage, property is owner, and the object is an agent.

The header approach is useful in cases when access to the description of the storage resource is unauthorized. The RDF statement is useful... wherever it can be read.