# W3C Solid Community Group: Weekly

* Date: 2023-01-25T14: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)
* [Matthias Evering(ewingson)](https://solidweb.me/testpro/)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* Henry Story
* [Matthieu Bosquet](https://github.com/matthieubosquet/)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* elf Pavlik
* [Ted Thibodeau](https://github.com/TallTed) (he/him) (OpenLinkSw.com) (hard stop 14:45Z)
* Seth Deegan
* RJ

---

## 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
* Virginia

### Introductions
* SD: I don't use Solid myself but interested in the standard and have contributed to things in semantic web. I was looking at TBL's contributions and found out about Solid.

---

## Topics

### PRs on Solid Protocol and Solid Notifications Protocol
* SC: Reminder about some open PRs and to contribute, e.g., review, raise questions/issues, propose changes on the Editor's Draft, or even to raise an objection.
* SC: This is also a great time to contribute with implementation feedback, help with the development of tests.

#### Add TR/2022/notifications-protocol-20221231
URL: https://github.com/solid/specification/pull/491

* SC: See also Call for Implementations: https://github.com/solid/notifications/issues/141

#### Add TR/2022/protocol-20221231
URL: https://github.com/solid/specification/pull/492

### Add Solid QA
URL: https://github.com/solid/specification/pull/495

* SC: Preview: https://htmlpreview.github.io/?https://github.com/solid/specification/blob/021b5d3b7ddffbf1da28827a028492b755f52dec/ED/qa.html
* SC: The document marked as Version 0.1.0 Editor's Draft to be published at https://solidproject.org/ED/qa , describes the Solid QA policy, processes, and procedures.
* SC: Work Item incubated in the [Test Suite Panel](https://github.com/solid/test-suite-panel/) as per the [Test Suite Panel Charter](https://github.com/solid/process/blob/main/test-suite-panel-charter.md).
* SC: Reviews welcome.
* SC: This is to document our testing processes and procedures for our specifications and test suite.
* SC: *screenshares*
* SC: This is version 0.1.0, edtor's draft. We have into, conformance section defining the kind of things that will be comforming: test report description, test case description, test suite description and assesment policy and criteria. TR report description, we are focusing on ???
* SC: Test case description: there's a model and refers to a versioned URL of a given spec and a requirement, which links directly to the requirement.
* SC: We do similar things with Test Report. Test report will be submitted when ???. Test review policy defined for example who can review, and the checklist for the test. For example, anyone can write a test but the original author probably needs to review to make sure that the correct things are being tested and the result are what's expected. Once a test case is approved, a report will be generated.
* SC: This is an early draft.
* SC: Test report notifications: we can accept notifications based on reports. We need to define whether it goes to an inbox or a GitHub process, different ways of getting those reports.
* SC: This has already been done in LDN Test Reports and Summary (URL).
* SC: We give a chance for a project mainer to review tests and results. So if there are exceptions as to why something isn't implemented, these decisions could be included in the test assertion information so that the consumer of the reports can have a better understanding of why for example one of the requirements was deemed inapplicable for that implementation.
* SC: The test suite will be described as well. The test assessment is policy and procedures to make sure they are reliable tests.
* SC: We borrowed a lot from QAWG (URL). Also from web platform tests (URL).
* eP: Describing requirements in a script tag, linking to requirements itself would not link to a paragraph in the text. How do you see it working if someone doesn't use RDF for annotating?
* SC: Are we talking about without using RDFa how do we refer to a requirement in a spec?
* eP: currently i use a fragment, the fragment is in a script tag data island, not in HTML. If you click on the IRI you don't see anything.
* SC: I think there is an example of that with [???](URL). The simplest way to make that URL useful is (*code suggestion*).
* eP: it might be useful to not require statement and if there's no statement extract the statement from the element.
* SC: The consumer may need to use the DOM (query selector, etc.), e.g., `document.getElementById('req1').textContent`
* eP: https://github.com/solid-contrib/specification-tests#annotations
* SC: That might be an implementation detail of the test suite. The technical report will describe itself. If not all information is available the consumer might need to make a decision to try to find other ways to find that information like the statement. We are not specifying to the level of how a test suite should get that information.
* SC: It's a work in progress. One of the test suites only copies ??? at the moment. The other one dereferences ??? but I don't think it does a DOM selection.
* SC: I will demo this properly some other time, but I want to show this: in the notifications panel, our concepts are very well defined, and one of the things required by ??? is that a specification define classes of products. For example in notifications we define what interoperability entails, and so on. These concepts are accessible. This application extracts all the concepts available, but also all concepts that are included in all cited documents: all dependencies or references that this article has, we can fetch some documents and build an additional set of concepts. All of this is still available from any document. And you can see a graph of those concepts.
* SC: The TR links to all these work items. The idea was to build a Solid glossary from all the specs.
* PAC: Thanks for the demo. All those sections giving definitions from other specifications, they are pulled automatically from the ??? specifcation?
* SC: Yes.
* PAC: That document with the definitions, is it one given spec or a central glossary?
* SC: This is the same as (URL).
* PAC: IT grabs concepts from RDF descriptions?
* SC: Yes. If resource is returning RDFa/Turtle/JSON-LD it is all the same.
* SC: All our technical reports can potentially provide this information.
* eP: Since you mentioned content negotiation, can solidproject.org support that?
* SC: https://github.com/solid/solidproject.org/issues/248 :)
* SC: But I don't thin kwe can do that with GitHub. Right now we have HTML served from these URIs of these documents, some of them have RDFa.
* eP: If you had it in a Solid server I dont know if implementations support that HTML ??? Does CSS support RDFa to turtle?
* SC: There is no requirement.
* SC: I know there are some issues to improve how we describe containers, and where RDFa fits in with writing/patching.
* eP: So it would rely on specific implementation and not protocol level.
* SC: Yes. Some implementations are doing that, equiopped with multiple RDF parsers, but on a spec level the minimum requirement is that turtle and json-ld are available for RDF resources. NSS does it, CSS does it, I do't know about others. I think there may be some interest in servers converting ???
* SC: Notification protocol is a good example of how to do comformance properly, really specifying the products that are expected to be implemented for it. And the communication between two products.
* PAC: That is interesting. I need to dig more as what spec is doing when derefencing definitions in other specs, because we have a lot of specifications that are not using RDF, but the semantics of HTML could be leveraged. Not so much about tests and requirements, but concepts and definitions.
* SC: There is webref (URL). You may be able to link to a requirement as HTML but there is no way of expanding a requirements ??? We're doing that because maybe it's useful but also demonstrates Solid.
* PAC: Agreed.

---

### Topic Proposal
URL:

* SC: Proposed by: