Sarven Capadisli

Results 854 comments of Sarven Capadisli

Generally agree that `rdf:type` may be inadequate for what's intended but I'm not sure at the moment if it is wrong per se. Minor comment requesting clarification: Was `http://www.w3.org/ns/ma-ont#hasFormat` intended...

I would suspect that for reading resources the proxy service can be independent / be anywhere, i.e., not necessarily part of a Solid server. For writing resources, it would probably...

@acoburn Indeed. I think a somewhat similar issue happens with access control, server-managed and configuration resources. These may be slightly outside the scope of this issue if we change our...

Just throwing this out there.. Thinking along the lines of the following behaviour: >gitignore - Specifies intentionally untracked files to ignore 1. An index of URIs can be tracked in...

Nearby [Self-review questionnaire: Societal Impact](https://w3ctag.github.io/societal-impact-questionnaire/) and the section for it in Considerations: https://solidproject.org/ED/protocol#societal-impact-review . Issue: https://github.com/solid/specification/issues/359

Max 1 until a good reason or a use case presents itself. Otherwise it is just hypothetical at this point. The minimal design (max 1) simplifies publishing and consuming -...

There can be multiple descriptive resources however only one is required for interop. Having multiples increases complexity in order to allow certain use cases. Are they significant?

I suggest to close this issue. Will label with "Waiting Commenter" for the time being prior to closing. https://solidproject.org/TR/2021/protocol-20211217 (Version 0.9) is taken to be the first published version of...

https://github.com/solid/specification/blob/main/meetings/2023-05-17.md#add-server-content-type-payload >RFC says `HEAD` is same as `GET` without the payload. When we add [[this](https://github.com/solid/specification/pull/524/commits/dd639ef5be43f02a6aee231f8d6185b80e2bd487])] new requirement, it ensures we get a content type in the `HEAD`.

Good suggestions. I think we should do both. 1) Reuse the RFC statement and change requirement level to MUST. The "unless" in the requirement helps to retain this from the...