Keep IRIs opaque to the client with iriPrefix

[elf-pavlik]

I was thinking about what we are missing to support use of IRIs opaque to the client. Main concern seems to be related to creating new resources. Looking at:

https://solid.github.io/data-interoperability-panel/specification/#datareg-create-instance

We could add two rather small changes to it:

1. Data Registration must provide IRI template or just base for creating new resource IRI, even something simple like void:uriSpece

2. PUT request creating new resource must have additional link in a header designating target Data Registration rel=http://www.w3.org/ns/solid/interop#targetDataRegistration

GIven above client and serve should still be able to create new resources in specific data registration. While it still allows server to use specific IRI hierarchy it doesn't require it.

[justinwb]

Agree we need a pattern like this for fully-flat resource spaces. Would recommend that we look at 1. as a property on the Registration class so it can be inherited by other registry types beyond DataRegistry

[elf-pavlik]

We could add two rather small changes to it:

1. Data Registration must provide IRI template or just base for creating new resource IRI, even something simple like void:uriSpece
2. PUT request creating new resource must have additional link in a header designating target Data Registration rel=http://www.w3.org/ns/solid/interop#targetDataRegistration

sai-js implements it alraedy

1. using interop:iriPrefix
2. using interop:targetDataRegistration

[justinwb]

Noting that from the panel session on 2021-10-05 it was agreed to put this on hold and consider pushing it upstream to be server managed. Unassigning it from the specification project / 1.0 milestone.