Consider revising Type Index Registration Entries

[csarven]

Re #type-index-registration-entries

The Type Index documents MAY contain any number of
statements of type solid:TypeRegistration which
map RDF classes/types to their locations in a WebID owner's
root storage.

Define Type Index document (or resource) focusing on its purpose and what its representation is should be, e.g., an RDF document that can hold any information, along the lines of https://solidproject.org/TR/wac#acl-resource-representation .

Then you can constrain it further with its data model.

So, consider clarifying the information about its purpose from the information related to its conformance. Remove MAY, and express along the lines of:

"
A Type Index Registration has the following properties:

• One rdf:type property whose object is solid:TypeRegistration.

(Reminder that the language you use earlier about how besides what the data model is, because it is RDF, the subject can technically be described further. Conformance doesn't break down if say the type registration has another class or an rdf:label or whatever. What's going to matter is the parts that required for interop, but the optionals doesn't break anything.)

Add all other properties to the list same way. This is going to be equivalent to the (SHACL) shape. For example:

• One solid:forClass property to indicate...

You can then approach the next two as two alternatives, e.g.:

• Zero or one solid:instance property to indicate...
• Zero or one solid:instanceContainer property to indicate...

As mentioned in #18 , clarify what the application should do when discovering multiples - in this case, explain how the application should handle this (error or not) when a TypeRegistration with both solid:instance and solid:instanceContainer are found.