Should .user include the full "extended profile" data?

[JordanShurmer]

This is more of a proposal than an actual issue.

The Solid Data Discovery documentation describes the following process for discovering where a user's data you care about exists:

1. Start with the WebID URI.
2. Use it to fetch the WebID Profile Document.
3. Parse the profile and load the other Extended Profile resources, which includes the Preferences file and any owl:sameAs and rdfs:seeAlso links.
4. From the Extended Profile, extract the registry links (the solid:publicTypeIndex predicate link to the public Listed Type Index registry, and the solid:privateTypeIndex predicate link to the private Unlisted Type Index registry).
5. Load one or both of the Type Index registry documents, as appropriate, and query them for the location of RDF Types that the app cares about.

However (assuming I'm groking things correctly), the user object that query-ldflex provides is only the data directly from the Profile Document, not including the "Extended" Profile data.

So, should query-ldflex populate the user object from the Extended Profile? In other words: Should user include step 3 in the above process?

[RubenVerborgh]

By default, LDflex will indeed only query the one document corresponding to the URL of the entity. For example, data[https://ruben.verborgh.org/profile/#me] will only read data from https://ruben.verborgh.org/profile/.

This is by design, and this is an important security/trust/provenance feature. With Linked Data, anyone can say anything about anything, so we cannot just pull in data from arbitrary documents. I actually think that the Extended Profile is a security problem and have filed an issue solid/solid-spec#189.

Which documents are allowed to be loaded, could/should be specific in a data shape on the pod (this is future work). But indeed, it does make sense in several cases to find data in multiple documents.