Allowing multiple descriptive auxiliary resources for a single resource

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.