Allowing multiple descriptive auxiliary resources for a single resource

[justinwb]

As defined in #156, Auxiliary Resources of various types are associated with Solid resources through link relations. There may be implications in allowing more than one linked auxiliary resource for a given type.

For example, if it was possible to link multiple ACL auxiliary resources to a single resource, there would be the possibility that authorization statements in one would conflict with the other, and the server would need a way to reconcile that. Consequently, it seems undesirable to allow more than one auxiliary resource of a given type to be linked with one resource, if it could result in the server mishandling operations for that resource.

In #156, we define five auxiliary resource types:

• Web Access Control
• Resource Description
• Shape Validation
• Server Managed
• Configuration

Web Access Control, Shape Validation, and Configuration auxiliary resources directly influence how the server processes a resource, and as a result there should only be one associated auxiliary resource of each type. Server Managed auxiliary resources are maintained by the server, so it would stand to reason that there would only be one.

Descriptive auxiliary resources (rel=describedby) are meant to contain arbitrary metadata. For example, a descriptive auxiliary resource for a binary image may contain supplemental EXIF metadata in RDF. While it would seem less issue-prone to allow multiple descriptive auxiliary resources for a single resource, it would also deviate from the regular pattern, and a good reason to do so is not readily apparent.

[csarven]

Max 1 until a good reason or a use case presents itself. Otherwise it is just hypothetical at this point. The minimal design (max 1) simplifies publishing and consuming - at least for the foreseeable future. If there is strong demand (implementation reports) to have multiples, the constraint can be relaxed on a case by case basis.

[justinwb]

@RubenVerborgh This issue was opened based on a comment in your editorial review, specifically questioning this text in the Resource Description section:

A given Solid resource MUST NOT be directly associated with more than one Descriptive auxiliary resource.

Do you have a use case in mind that would warrant expanding beyond a 1:1 relationship between the resource and the descriptive auxiliary resource associated with it?

[csarven]

There can be multiple descriptive resources however only one is required for interop. Having multiples increases complexity in order to allow certain use cases. Are they significant?