# W3C Solid Community Group: Specify Container Description

* Date: 2021-11-05T14:00:00Z
* Call: https://meet.jit.si/solid-specification
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification

## Present
* Justin B
* Aaron C
* Sarven C
* Noel DM
* Alain B
* e Pavlik

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Join queue to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Aaron C
* e Pavlik

### Introductions
* name: text

---

## Topics

### Specify Container Description
URL: https://github.com/solid/specification/issues/227

* Aaron:
1. What data is required in read requests
2. How is that data expressed
3. Where to clients retrieve that data
4. What are the consequences for writes
* eP: it would be good to focus on use cases or at least base the conversation on specific use cases
* SC: Please q+ if you have specific use cases
* SC: The main use case was captured in initial comment. This is related to data used by current apps.
* SC: Are there other use cases? If not we can move on to the questions
* SC: Should we reorder the questions
* AC: I ordered them as I understand the problem
* AC: 2 should be after 1, 2 gets more specific

#### What data is required in read requests

* SC: There is a [table](https://github.com/solid/specification/issues/227#authoritative-data-in-the-wild) with comments about what data should be present and information about what properties are used by existing applications
* SC: Are there any data missing from this table (i.e. from servers exposing properties or properties needed by apps)
* SC: when a client performs a GET on a container, what is in the response? Typically, the subject of the RDF is the container. This includes containment statements. Can we know more about those contained resources? We should distinguish between the statements about the container and those about other resources
* eP: where will these data come from? Will it be from server-managed resources? or from the resource itself?
* SC: can you elaborate on the server-managed data?
* eP: e.g., the creator or timestamp
* SC: do you mean the authoritative data vs. the resource?
* eP: for instance, the creator might store that in a dedicated resource
* AC: I think we need to distinguish between data about resource eg `/foo` and data about the resource. There might be auxiliary resource ...
* AC: We should distinguish were something is materialized. If one piece of information is who created contained resource, it doesn't matter where it is materialized.
* JB: in terms of different types of data, "creator" is useful. Who last modified is useful. I didn't see something in dublin core for modified by
* SC: Activity Streams has `attributedTo`. Prov-O has `wasAttributedTo`.
* JB: there are a lot of feelings about what these attibutes are, and whether they are fine to show all the time with basic authorization, it would be good to get a base set. Perhaps we can get close to that today
* SC: it isn't so much about specific property names
* AC: creator and modifier are controversial with regards to privacy, can we focus on less controversial things first.
* JB: i just try to get across, if you speak about specific resource, I don't think there is agreement about what is included. There is no agreement about what data are maintained internally per resource
* AC: I think `rdf:type` is non-controversial. Also `ldp:RDFSource` etc. For conditional request also last modified time. And for non-rdf sources the mime-type
* eP: maybe etag as an alternative to last-modified
* SC: dokeli is described in table. It was implemented before the slash semantics requirements. With slash semantics, if you do something beyond container/non-container you don't need the rdf:type, you just need the URI.
* SC: We should decouple what info is of interest from its visibility/authorization. Making creator/modifier available can leak information. We shouldn't spend too much time thinking about authorization for this. Does "Creator" require access controls?
* SC: distinguishing between rdf/non-rdf-source can be handled with format. Also, I would caution that LDP makes a strong distinction between those two, but that is not the same view that we have in the Solid protocol
* eP: the source of the statement relates to access control. Because the statement might be included only if you have access to the resource where the triple is materialized.
* SC: for authoritative data, is that based on per-statement access control? Perhaps the simplest thing is to not go to the per-statement access control. At least not for the current version of the spec.
* SC: the questions are good, but we should move on
* SC: the kind of data is less controversial
* AC: can we get proposal for non-controversial data ?
* JB: +1
* AC:

PROPOSAL: For container descriptions, a container MUST include ldp:contains triples referencing all child resources

* eP: what about paging
* AC: I'd love to deal with paging. Let's defer it but I'd like to come back to it

* eP: +1 - given paging will be addressed
* AC: +1 (we should deal with paging)
* JB: +1 (agree to defer paging for now - need to revisit)
* SC: +1 - containment statement (`ldp:contains` is the best statement at the moment.) - if Solid Protocol moves away from LDP , it could be `solid:contains`. Deal with paging separately.

PROPOSAL: For container resources, a container MUST include the MIME-Type of all non-rdf child resources, such
that the subject of the triple is the contained resource and the object is the mime-type

* eP: +0.5 for Non-RDFSource - might be less needed when using shape trees
* SC: +0.5 - cutting close to representation that exists or could be generated.
* AC: +0 (we may have other conneg mechanisms to deal with, e.g. PNG -> JPEG)
* JB: +0

* AC: dcterms:format might be one way to express it
* JB: jzucker was saying that mime-type is really useful. Especially for the client applications that he has been building. I suspect that he would be +1 on that proposal
* SC: That is my interpretation, but we can't use that as a vote
* JB: That was just proposal #2. Even if we settle just that, how many problems would we be settling right now with this? That would be progress.
* Alain: Why non rdf?
* AC: for non-rdf we can tell the content type, for RDF it is content negotiateable, they are abstract resources not any specific representation.
* Alain: I would like to know my original content type eg. text/turtle That information seems to get lost.
* NM: why is it important to know that?
* Alain: in some representations that information is important (comments, whitespace)
* eP: there is a recent issue on that https://github.com/solid/specification/issues/342
* SC: even if it says "text/turtle", there is no guarantee that the same (byte-for-byte) representation is the same. There is nothing in place that expects that sort of RDF serialization round trip. In that context, the text/turtle would be treated as a non-rdf source type.

PROPOSAL: Container representation MUST include statements about contained resources in which the property is about the last modified time.

* AC:
* SC:
* JB: +0

#### How is that data expressed

* AC: I want to make a case for using properties that we define in `solid:` namespace. Ultimately they are coming from server managed data. IF we define properties in solid namespace, this will allow us to treat them as reserved properties. If I patch container description we will not have chance to collide. One client could use it in one way and trick another client to use them in a different way.
* JB: +1 to using `solid:` namespace for properties
* AC: If we take existing name space, client might want to use that namespace in a way not intended by solid spec which reuses the property. Defining props would give us full control on how they are intended to be used.