Clarify the notion and mechanisms for server-managed information

[csarven]

What are the conceptual and implementation differences between server-managed containment triples and the triples in server-managed resources (auxiliary)?

It appears to be that we have two different mechanisms in the spec that are conceptually similar, if not the same. How can we reconcile this?

Containers are self-descriptive in that the containment information is part of the resource description and managed by the server. Contained resources are tied to the lifecycle of the container. Container may include other information provided by clients. Containment triples can't be updated by clients.

Server-managed resources (auxiliary) are independent resources discovered through primary resources and are tied to their lifecycle. Server-managed resources are not writeable by clients.

We can see that although cumbersome, containment information can be found in a server-managed resource (auxiliary). We can also see that any information that can part of a server-managed resource (auxiliary) can instead be in a self-descriptive resource.

[justinwb]

We can see that although cumbersome, containment information can be found in a server-managed resource (auxiliary).

It's true that you could store containment triples in a server managed auxiliary resource associated with a container, but I'm not sure that we have to.

We can also see that any information that can part of a server-managed resource (auxiliary) can instead be in a self-descriptive resource.

It is true that you could store the same information in a regular Solid resource as a server managed auxiliary resource, but the provenance would not be the same. This is the key value in the server managed auxiliary resource type. No agent would have the ability to directly write or modify the data in a server managed resource. A consumer of the data in a server managed resource can have confidence that the data inside it (i.e. timestamps, creator, etc) was written by the server and no-one else.

[csarven]

The point of this issue is to note and justify why we have one mechanism where a server controls certain kind of information and yet another mechanism for other information. It seems to be a bit of an arbitrary split.

---

but the provenance would not be the same.

Explain.

No agent would have the ability to directly write or modify the data in a server managed resource.

Holds true for containment triples in the container resource that is managed by the server:

Containment triples can't be updated by clients.

Clients affect resources directly and indirectly eg:

Client requests to append/remove a resource to/from a container. Only the server manages the containment relationships.

Client requests to create a resource. Only the server manages the creator relationship.

It is not apparent why a container (or any other resource for that matter) can't be self-describing especially when it comes to information like "timestamps, creator etc." It is already doing that for containments as well as other information. Aside: Some of the Solid servers exposed posix information in the container, and client have nothing to do with it.

If the server-managed auxiliary resource had its own lifecycle ie. potentially outliving the resource it is about, that'd be a clear enough reason to keep the server-managed resource decoupled from the primary resource. It would allow the server-managed resource to be more useful and preserved independently. But that's not what's intended or within the scope of this auxiliary resource. If there is no value to preserving the server-managed information beyond the primary resource's lifecycle, why isn't the information in server-managed resource part of the primary resource - further supporting self-describing documents? I don't think the access modes is significant because the underlying information is deemed to be server protected regardless of where it resides.

It is more intuitive to find something about the resource at the resource than at another resource. Not a whole lot different than finding the Last-Modified HTTP header (which is server-controlled) where one would expect.

---

Just a thought: server-managed auxiliary resource seems a notch too broad / catch all. Would it help to bring it down a layer and frame it around provenance level information? We don't lose out on timestamps, creators etc. or it being server-managed (ie. read-only for clients). It could be expressed along the lines of activities, entities, agents (eg. PROV-O).

If the information that's intended for server-managed resource is dependent on the primary resource's lifecycle, it'd be relatively simpler for a server to manage that through a single resource instead of two. It also has minimal Web-footprint. Decoupling or perhaps loosely coupling the two resources may be preferable if different lifecycles have value.

[jaxoncreed]

It is more intuitive to find something about the resource at the resource than at another resource.

I disagree with this. It makes more sense to be able to filter out metadata. A "resource" is a thing and only that thing. It shouldn't need to include extra information. I'm in favour of using link headers to discover metadata.

[elf-pavlik]

During the call we also discussed Non-RDF Sources as well as resources with digital signatures. In both cases server can't really add triples to those resources.

[csarven]

@jaxoncreed On the contrary, we are not in disagreement. I didn't claim that resources should include metadata. Containment information and server managed auxiliary information are part of resource description. I consider them as data. There can be separate resources describing provenance information, history/audit, access logs etc.

We reframe what's intended for "server managed" to specific kinds of resources. For example, proposal for clients requesting to create Memento's URI-R and have the server create URI-M, create/update URI-T: #61 (comment) . Essentially include header:

PUT https://csarven.ca/linked-research-decentralised-web
Link: <http://mementoweb.org/ns#OriginalResource>; rel="type"

201 Created
Location: https://csarven.ca/linked-research-decentralised-web

A client can for example discover a resource's URI-M and URI-T from the link relations:

GET https://csarven.ca/linked-research-decentralised-web
Link: <http://mementoweb.org/ns#OriginalResource>; rel="type"
Link: <https://csarven.ca/linked-research-decentralised-web.timemap>; rel="timemap"
Link: <https://csarven.ca/archives/linked-research-decentralised-web/ce36de40-64a7-4d57-a189-f47c364daa74>; rel="memento"

Or discover provenance information through eg. rel prov:has_provenance. Use specific properties to discover audit, access logs. They can all be managed by the server.

@elf-pavlik Makes sense. The context was RDF sources any way. [My point was about server's capability, not whether they can, should, or not for any arbitrary resource.]

[justinwb]

@csarven I'm not sure I have a firm grasp of what you're looking to see changed for server managed auxiliary resources in the current proposal at #156.

From what I can tell, you support the use of link headers to discover server managed data in auxiliary resources (which is described in #156), but want those relations to be more specific, rather than one single catch-all for "server managed" data?

[csarven]

@justinwb That's right. Key points:

• Server managed auxiliary resource is too broad (vague) for clients. In theory it can contain any information that the server deems useful, but it needs a specific shared data model for it to be actually useful for clients.

• With a single relation for "server managed" information, clients will not know whether the description in the auxiliary resource is actually useful to them until they fetch and inspect.

• General rule of thumb: resources should describe themselves. If the most recurring subject of the statements in server managed auxiliary resource use the same identity as in the primary resource, it is better to describe that identity in the primary resource eg. "R creator x" or "R date y" should be in the primary resource. This is the same pattern as the one I've discussed about where to put resource labels - they are not "metadata"!

One way to move forward:

• Use specific link relations to indicate the kind of information that's expected at the target resource eg. provenance, audit, access logs - however the kind of information that the server wants to expose need to be sliced. For instance, the notion of provenance information is sufficiently precise and used in the wild. There is a specific relation available that can be loosely coupled with the Provenance Ontology or others. Same goes for Memento where the client can knowingly follow a relation to obtain Mementos, TimeMap and so forth.

• The specific relations can still be managed by a server ie. only the server can write/append, as originally intended. But this ought not be the focus. It is just that there is no (strong) use case for an arbitrary client to modify the activities that a server observes - hence, read-only for authorized agents.

---

If the entities described in the auxiliary resource are significant and should have their own dereferencable identity, that's a clear enough indication to have them in independent resources instead of lumping it under the representation of the primary resource.

[justinwb]

@csarven Thanks for clearing that up, I think we're in agreement, and this also lines up with feedback from members of the data-interopability panel.