Ability to have general metadata

[damooo]

Current linkset metadata resources have very basic capability to express only metadata that can be encoded in HTTP link headers. But it is essential to have a resource to encode general description with full power of a description language (say, RDF), that also bound to primary resource's lifetime. For RDF info-resources, we can self-describe. But for Non-Rdf resources, a general metadata resource with same lifetime is essential. This also helps in porting applications/servers that are coded against Solid's resource organization model.

This can also be solved with support for general notion of auxiliary resources.

[gibsonf1]

Current linkset metadata resources have very basic capability to express only metadata that can be encoded in HTTP link headers. But it is essential to have a resource to encode general description with full power of a description language (say, RDF), that also bound to primary resource's lifetime. For RDF info-resources, we can self-describe. But for Non-Rdf resources, a general metadata resource with same lifetime is essential. This also helps in porting applications/servers that are coded against Solid's resource organization model.

This can also be solved with support for general notion of auxiliary resources.

For the implementation case of TwinPod, all resources have RDF data associated with them. So from an implementation perspective, the linkset would be generated from that, but the source of truth would be the actual resource RDF data. So no need by far to create yet another separate resource about the resource.

[damooo]

For the implementation case of TwinPod, all resources have RDF data associated with them

That is what to be standardized. A way to attach and operate on general rdf description as an addressable resource. The fact that linkset is generated from that is implementation specific.

[acoburn]

This is being actively discussed in #165 (and related #167)