TypeIndexen and DataRegistrationen

In thinking about how the profile discovery process can be most compatible with interop proposals, I am wondering about combining approaches.

A typeIndex links a type and data e.g.

[] a s:TypeRegistration; 
    s:forClass bk:Bookmark; 
    s:instanceContainer  [a ldp:Container] .

So suppose we could also say

[] a s:TypeRegistration;
    s:forClass s:SoftwareApplication;
    s:instanceRegistration  [a interop:DataRegistration] .

This allows apps to keep all information about the type and location of the data in a separately controllable resource without divulging that information to all who read the type Index, solving, I believe the interop panel's main objection to the type indexes.

The big advantage of allowing this path to the DataRegistration is that the profile discovery process will be the same except for the final steps.

1. Load the WebID document
2. Load the privateTypeIndex.
3. Look for s:instance* predicates
4. Follow them to a resource, to a Container, or to a DataRegistration with a link to a shape tree.

This would support existing apps, new-style apps, an easy transition from one to the other, and the ability of both styles of apps to find the data they have access to regardless of which style app created it.

Start by reading the issue's proposed profile-discovery sequence, including the WebID document, privateTypeIndex, s:instance* predicates, and DataRegistration links. Review the 20-comment discussion for an unresolved decision; done would be a settled specification direction for whether this discovery path should be supported.