Background: to date, the Solid Protocol (including earlier drafts and issues) only required server-managed containment statements in the representation of a container. Additional information such as last modification, size, resource type etc. about the contained resources as part of the container representation was deemed to be optional or considered to be a best practice. Examples in the wild show that some servers do make this additional information available, meanwhile some other servers do not support it. Some applications do make use of the information if available or work around the limitation to get a hold of the information [Anecdotal Evidence]

General use case:
Support navigation of the container and its contents.

Use cases:

• Guinan is viewing a list of their social assets (eg. photos, blog posts) and wants to select and view a resource by its human-readable name.
• Janeway is viewing their inbox and wants to respond to unread notifications from oldest to most recent.
• Dax is viewing their collection of short-films and wants to delete the ones occupying significant portion of available storage quota.
• Burnham is viewing a list of their crew's personal logs and wants to archive the ones that are created by certain individuals.

Related UCs:

• https://www.w3.org/TR/ldp-ucr/#uc3
• https://www.w3.org/TR/ldp-ucr/#uc5
• https://www.w3.org/TR/ldp-ucr/#uc6

Scenarios to consider:

• Resources with URIs having non-human-friendly path segments eg. https://example.org/{uuid}
• Container including mixed resource types eg. containers and non-containers, resources with different formats or media types.
• Container including public and access controlled resources.

General requirement:
Include descriptions about contained resources in container's description to further support navigation and application interaction.

Specific requirements:

1. Any information (eg. human-readable label of resources) that may be client or server-managed.
2. Server-managed (controlled) information (eg. last-modified, resource size, resource types for controlled interaction models)

Considerations:

• Some resources may require authentication and authorization, and in those cases information about those resources must not leak into the container description.
• Is there empirical data on container response times making certain kinds of information available about its contained resources?
• What would the application UX be like when device and network constraints are taken into account?
• What's the cost for servers when this data is not used by applications?
• What information must a server make available in container description (besides containment triples)?
• Caching, caching, caching..

Related issues:

• Specify metadata mechanism for Containers, RDFResources, NonRDFResources #63
• Proposal: server-protected metadata #65
• Specify container listing mechanism #116
• Container Data Augmentation #144
• Clarify the notion and mechanisms for server-managed information #177
• ..

Notes:

• Some servers may be read-only and do not require authentication or authorization, hence, the requirement to check access privileges per resource (in order to expose additional data about the resource) is inapplicable.
• If additional information about a resource is made available in the container description, how does that effect write operations on the container eg. server ignores statements with certain (server-managed) properties?
• Instead of the container resource, the associated description resource of a container (ie. target of describedby) could include information about the contained resources. Doesn't violate best practice on self-describing documents per se but it is perhaps not the most intuitive place to look for additional information about the contained resources.
• Would requiring the client to explicitly request additional information through the Prefer header be meaningful?