Confirm that solid:instanceContainer container contains documents containing instances?

[josephguillaume]

The spec says:
"solid:instanceContainer - This predicate maps a type to a Solid container which the client would have to list to get the instances of that type."

My understanding is that this should be interpreted as
"a Solid container containing documents which the client needs to read to get instances of that type."

This interpretation provides an affirmative answer to:
#30 (comment) "A container contains documents, not instances of the given type. So does it mean I have to read all documents contained in the container and consider all instances of the type found in those documents?"

This interpretation is based on:

1. This seems to be how it is implemented in practice at the moment
2. The notion that "Linked data is a set of documents" Add predicate to link TypeIndex to TypeRegistrations. #8 (comment)

Additionally, to maintain an open world assumption, it appears that not all the documents in the container are required to contain instances of the registered type.
This may cause surprises, with clients parsing data they do not expect to parse or did not need to parse.
See e.g. NoelDeMartin/media-kraken#34 (comment)

[josephguillaume]

A counterexample in solidos, where the objects of ldp:contains will directly be of the class defined by solid:forClass.

:photos solid:forClass schema:Image; solid:instanceContainer  ${AlicePhotoFolder} .

https://github.com/SolidOS/solid-logic/blob/efa1982bb7c91373121c723952b8d7b1fc915e4e/test/helpers/dataSetup.ts#L68

[jeff-zucker]

Can you give an example of what you mean by a document needed to read an instance and how that would be (or is) used with the type index instanceContainer? To me instanceContainer points to a container which contains records of the type specified in the forClass e.g. image files, sioc posts, vcard records. I would expect each to be contained in its own resource.

To me, the case of a document that contains pointers to instances should be handled by instance, not instanceContainer. I see these as the potential relationships between the type index and instances :

solid:instanceContainer points to a Container whose contained resources include

* instances of the forClass (e.g. photos or email messages or vcard records)                    
* documents which point to instances of the forClass (?)                                        

solid:instance points to a subject in a resource, subject points to instances

• subject points to a list or collection of instances of the forClass
• subject uses its own relationships to point to instances of the forClass (e.g. skos)

solid:instance points to a subject in a resource, subject does not point to instances

• instances of the forClass point back to the subject using an inverse memberOf-like predicate

solid:instance points to a resource

• the resource contains instances of the forClass with no explicit contains predicate

Should we explicitly say these are the possibilities? Or should we limit some of them?

See the discussion starting at https://matrix.to/#/#solid_solidos:gitter.im/$AzSC4daFzrgRwt-FDuuB61wOY3rs4hwTcihI-5g3xeE

[josephguillaume]

As an example, Umai's structure uses instanceContainer with an LDP container in which each document has a schema:Recipe object.

NoelDeMartin/umai#22

Media Kraken uses the same pattern and here's an example:
https://jg10.solidcommunity.net/movies/example/