# W3C Solid Community Group: Weekly

* Date: 2023-05-10T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* elf Pavlik
* Jeff Zucker
* [Hadrian Zbarcea](https://hadrian.solidcommunity.net/profile/card#me)
---

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
* 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.
* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

### 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
* Sarven
* Pavlik

### Introductions
* name: text

---

## Topics

### Overview of today's agenda

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
* eP: ...
* SC: Played with blob nd someting else IIRC in dokieli's "save as.."
* eP: we use authenticated fetch. We get a blob from response. If you pass that to url createObjectURL, the resulting URL is something you can use in source of the image or as the download file. So far it works. Haven't tried with images that exceed available memory. For now we use that method for most basics and whatever attachments people want to use.
* eP: In sai-js I use UUID.. no intention to use anything human-readable in the URI. Re download, I plan to have it as part of the resource description - part of the metadata not URI. Possibly also include media type information. CSS takes content-type from the request. It preserves the extension if filebased system used. I was thinking of using content-type in the resource description. If you have some kind of attachment, you coudl get some kind of icon to represented. one of hte motivations no tot URI because to use human-readable label without changing the URI.
* SC: You mean "Description Resource" right?
* eP: Yes. linked with "describedby"
* SC: If you don't have human readable label, everything after the last slash is used
* SC: One convention used when no RDF label is available, then use string after # or last /.
* JZ: With the way URIs are built, can't do anything - not reliably reveal users' name. For practical reasons need to do something. In solidOs there is a method called label, and it tries to come up with a human-readable label. It is a bit more complicated than # / string but same idea.
* eP: Shapes trees provide a way which predicate to use for the human.
* eP: It is generic / not domain-specific. If you have FOAF, you'd specify in a shape tree, that foaf:name would be the one describing the label. The subject would be the identity of the resource and a particular predicate would be label.
* SC: In dokeli before it gets to use string from URI, it tries some common properties and are commonly reused, for `foaf:` it makes sense to use for `foaf:name`, one can also try `rdfs:label`.
* eP: in ShapeTrees we have advantage of conforming to a specific shape so a predicate can be used from the ones that are required by the shape.
* SC: It depends if the model is more strict/controlled or is more free mix of vocabs. In HTML documents people may use schema.org or DC terms or RDFS.
* eP: on mobile, they tend to show just the domain
* SC: or doesn't fit the screen even
* eP: IIRC, Safari.

### Change JSON-LD context URI in Solid Notifications Protocol

* SC: https://github.com/solid/notifications/pull/174
* SC: `https://www.w3.org/ns/solid/notifications-context/v1` will be the first published URL.
* SC: No need for .jsonld right? Only available in JSON-LD any way.
* eP: Yea, current practise is to not include it.
* SC: If we publish spec and publish JSON-LD context, we are okay.
* eP: Context can be published ASAP.
* SC: Spec needs to refer to it before publishing. ED should be sufficient for now. We can nudge W3C Team to follow-up right after merging of 174 to publish the JSON-LD Context.

### Solid Protocol Release 0.11.0
URL: https://github.com/solid/specification/milestone/7

* SC: Have started to mark items towards this milestone.
* SC: Suggestions and commitments welcome.
* SC: There are other milestones like FPWD, e.g., https://github.com/solid/specification/milestone/1 , which I created a long time ago. These are good candidates towards 0.11.0. See also https://github.com/solid/specification/milestone/2 and https://github.com/solid/specification/milestone/3 ..
* SC: Apparently also moving items from https://github.com/solid/specification/milestone/6 to https://github.com/solid/specification/milestone/7 .
* SC: When I created these milestones, the idea was to take up the issues based on importance of publishing a REC in the WG. Those maturity levels don't have standing in the CG. If the WG happens it will need to do the same exercise since the maturity levels apply to the WG.

### Solid QA
URL: https://solidproject.org/ED/qa

* SC: We need to advance Solid QA, including all the related work (e.g., test suite development, tests). It is at the heart of TRs - "gives Solid projects confidence that their software is compatible with other implementations." So, please contribute to the development. Advancing TRs and QA work go together. This is the required ground work in order to inform about the level of adoption of TRs.
* SC: There is no real spec until we have test suits and implementation reports. If there were no implementation for a feature there is no reason for it to stay in the spec.
* SC: We have monthly Test Suite panel meeting, next week on Tuesday will be the May meeting. Spec authors and editors need to be closely involved in the test suite work to verify its accuracy. If we are not able to do it here I don't know how are we going to do it in WG.

### Update background to clarify Solid and comparisons
URL: https://github.com/solid/solid-wg-charter/pull/30

* SC: Resolves https://github.com/solid/solid-wg-charter/issues/5
* SC: There are three thumbs-ups and 1 review so far.
* SC: Feedback?
* SC: Any objections to merge?
* SC: Assigned to PA.
* eP: I saw PA announced that it is announced to Members, so which version is it - one changing.: https://lists.w3.org/Archives/Public/public-new-work/2023May/0002.html
* SC: He refers to the advanced notice. It needs to go through the horizontal review and it will come back. For example, Web Accessibility, I18n, TAG may provide some feedback and request clarifications. Once we do that the W3C members will get to vote on the charter, which can result in more issues and PRs. The charter is always in edit mode until it is accepted. Only then W3C will create as snapshot on w3c.org, and even then there can be changes done by re-chartering.
* SC: If no objections, we'll leave it to PA to review/merge.

### Clarify normative, tentative, new Deliverables
URL: https://github.com/solid/solid-wg-charter/pull/28

>* PA: Yes, I will review this PR and try to get feedback from other W3C people about how to address this. I like the idea to list them as other "adopted" drafts; however, this might indicate a stronger commitment.
* SC: yet another normative spec is WHATWG/Fetch with Living Standard status. Obviously we won't be taking that up or wait for in the WG. We refer to Fetch for CORS. Perhaps goes to show that not all dependencies need to be Recs!?

### Scope needs to be tightly defined with narrow focus
URL: https://github.com/solid/solid-wg-charter/issues/9

* SC: Related issue https://github.com/solid/solid-wg-charter/issues/29 that can move to issue 9.

### Update mission
URL: https://github.com/solid/solid-wg-charter/issues/7