# W3C Solid Community Group: Solid Editors

* Date: 2021-10-20T13:00:00Z
* Call: https://meet.jit.si/solid-specification
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* Justin B
* timbl
* Ruben Verborgh
* Kjetil Kjernsmo

---

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

### Introductions
* name: text

---

## Topics

### Solid Community Group meeting at TPAC 2021
URL: https://www.w3.org/wiki/TPAC/2021/GroupMeetings

* SC: Agenda review: https://github.com/solid/specification/pull/327
* SC: Any feeling on PRing agendas in general (may be more useful for panels..)
* TB: Make sure to ping people. Don't just leave it for too long - specify time/people.
* JB: +1

### Format / Agenda for Implementer Feedback Session
URL: https://forum.solidproject.org/t/solid-implementer-feedback-session/4754

* JB: Propose that each implementer who RSVP'd have a dedicated timeblock to provide feedback. Editor group has a timeblock to ask follow-up questions. Focus on information gathering.
* JB: Good mix. Some companies and individuals.
* JB: We should be there to listen. Not make decisions or provide too much background. Allow follow-up questions to gather more information. We don't get enough of this from individual developers or companies.. what they're experiencing or running into.
* JB: We have 9 slots.
* JB: Low overhead. Not trying to prioritise what issues to tackle on. We give a block of time and listen. We use that is input.
* SC: How long is it? I'm okay to give up my spot or go last..
* JB: 1h. Should be able to stick to it. If it flows well, we can have another.
* JB: Propose for next session to use github PR (similar to PRing agenda/minutes) for submission rather than e-mail. Agree with SC. Okay for now though.
* JB: Push initial agenda. People can PR their submissions.
* RV: Some of those people have multiple hats, especially in CSS it is me. Agree with SC on going last or giving spot. What to do with people with multiple hats?
* JB: Case by case. It'd be good to get feedback from CSS. Same for SolidOS. Small community of implementers.. we shouldn't limit who speaks, and try to put our ???
* TB: Should we invite someone else from CSS team? Useful to ask Timea for SolidOS (Project leader).. mainly to listen.
* KK: The problem we have with progress on the spec has to do with what people like to work on future things. We need to exercise discipline so we can address the things to have v0.9+. We're coming out a lot of commitments for future things but we need time for immediate things. Love to have the feedback but concerned we're getting derailed.
* TB: We make a lot of requests. Brainstorming what we've forgotten. We may not meet again.. this group will think of things that can bring up things that may not normally. Prioritisation is the same. To the extent that everything they throw in there.. put it on the list. We can also ask them about prioritisation. If someone says they got a new gadget in CSS and want that in spec, we can push that.
* JB: Agree with KK. I've volunteered to take on what comes out of this session. Will try to have format that we can have a look at. We talk about prioritisation but don't have enough information. We have opinions. There are people out there trying to use the spec to make business/research. Their opinions should weigh in. That will help us move in a more efficient way. We'll learn a lot.
* SC: re multiple hats, I'll be totally wearing my developer hat.
* SC: What is it you editors people do any way?

ACTION: JB to PR agenda.

#### Implementer RSVPs (received so far):

* Ruben Taelman - Query
* Inrupt - Osmar Olivo, Nicolas Mondada, Geoff Pirie
* Sarven Capadisli - Dokieli
* Janeiro Digital - Jamie Fiedler, Justin Bingham, Angel Araya, Eric Prud'hommeaux
* CSS - Ruben Verborgh
* Tim Berners-Lee - SolidOS
* Jeff Zucker - solid-ide, solid-shell, solid-file-client, et al
* GraphMetrix - Fred Gibson
* Christopher G. Prince - Swift Packages for Authentication

### Create best practices for profile predicates
URL: https://github.com/solid/data-interoperability-panel/issues/209

* SC: Jeff Zucker is keen to turn https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md into a recommendation.
* TB: SolidOS has some stuff that i'd like to see. cv, who you work for etc.. that'd be a different spec but I'd like to capture what we can use. Some of those are used with forms. Converting to shex - but don't have a tool to convert. have Forms into SHACL. would liek shaclshapes because i can make those automatically. particularly contacts.
* JB: Good idea. Would be nice as a standalone document. Going to ref diff specs and implementations. Good opportunity for diff groups to get their stuff work together. +1 to JZ.
* TB: It'll be in the same repo?
* SC: solid/specification . it'll enbd up under TR/
* TB: as long as separate diff documents.
* RV: Suggested shape for profiles. Long term compatibility. We hope that in the long term tahnks to RDF.. they can write profiles in A then to shape B. I'd be in favour of having it somewhere else. This is implementer guidance.
* TB: Disagree. Spec is really important. All these chats work together because they use the same shape. We don't have all engines working in all ??? You don't hae rules for rule language spec. We need rule level expressivity. Keeping it fast and interoperable is very important. Rolling out chat.. contacts.. fitness.. bank statements.. where we have XML formats and calendars and roll out these specs and everyone to commit to them.. It is a wonderful vision to convert all these ontologies but it is very futuristic.
* RB: I agree but we should be careful. Other projects do have specific shapes.. cars, boats.. they are able to get started much faster because they agree on the strength and weakness. We shouldn't undermine the tech. We have the complexity of the spec but also the advantages.
* TB: When you put someone's name there is a way to recognise it. for a lot of things like bookmarks, meetings.. we can take advantage of the fact that we are the first.
* RV: Do these things need to have the same governance model? I suggest a seaparate proposal to get people started.
* TB: eg.. how do I find user's storage? ... it is the next level of spec. we can say these people are only the server knows about..
* RV: someone define the shape for a person.. we all use that today or?
* TB: yes.
* JB: I think Jeff's initial ask for the scope of this effort was. Phase 1) what are some of the key properties e.g. oidcIssuer. Not a lot of places to go for that other than the OIDC spec. TB yo bring up actual data ecosystem. We don't necessarily have decide on that in this document. In the interop panel, we're just about getting going.. trying out different processes for people to submit. Open domains / shapetrees. We don't have grand designs on process yet but try it out. Just start getting people to contribute to what they're using. Still in its infancy but in a good spot. We're looking into some of these ecosystem items.
* TB: anyhting in the shapetrees world is compelte incompatible with the solidos. we don't use type index. you can have a shapetree jungle with an item thign.. you ca nmake the world with it .. first you find user type index.. where type tree jungle is.. a tool that a developers can use. eventually it'll be tied into type index. i know you have good reasons to make it more complicated but it'll be incompatible.
* JB: first point what jeff is looking at is getting different groups working. this can be how to reconcile differences. for starters agreeing on common schemes.
* TB: by this you mean a new group or the interop panel.
* JB: we don't have to create a new panel. it can be incubated in the interop panel
* TB: I prefer a differet grouping. for example putting your storages.. putting your cv in your profile, withyou hav ea shapetree for cv and to find any job shape.. that would be stored at a place where a ?? useful to put shapes in..
* JB: Shapetrees and interop spec are different specs. You said shapestrees is incompatible with solidos but that's not true. for interop spec, it can benefit.
* TB: you say shapetrees to decide how to store contacts
* JB: yes
* SC: Let's use the opportunity to diversify. Suggested that JZ could edit. Also like to nominate Virginia Balseiro. (I can help edit/assist, if needed.)
* SC: notes group agreement

RESOLUTION: let JZ and VB and Timea (if intrested) go for it.

### Milestone: Current Month
URL: https://github.com/solid/specification/milestone/5

### Specify container description
URL: https://github.com/solid/specification/issues/227

### SPARQL Update semaphore
URL: https://github.com/solid/specification/issues/322

* KK: People who have SPARQL implementations don't have to do too much to support this.
* KK: What's difficult is .. in the situation where you want to have an error.. DELETE INSERT WHERE query.
* TB: You're talking specifically about semaphore?
* KK: Yes. No way for SPARQL engine would communicate that outwards.. and therefore they'll put in a lot of logic to communicate the total counts to the upper layer and therefore to raise error. There are exceptions: some engines can do that. But not something I commonly see in SPARQL engines.
* KK: It might be dififcult to ask something from implementers.. this tension may mean that people might not implement this part. Can we live without that? Wouldn't you indeed use those cases.. DELETE INSERT DATA pattern, instead of DELETE INSERT WHERE pattern where you have a variable.
* TB: SPARQL spec is designed.. always the condition being there. I'm a bit concerned that what we're doing is asking different SPARQL mode to run e.g. content-type line.. I'm a bit owrried about those ways.. basically you're saying there are two specs that will cause it to be implemented. If our SPARQL engines just update this with this violation.. that could be reasonable.. because Solid Patch is not SPARLQ Update at all. SHouldn't we give it a different spelling e.g REMOVE instead of DELETE so people can see it. If people dont' want ot implement it.. that's fair. If people see REMOVE instead of DELETE they can pick up the conflicts.
* KK: There's been quite a bit of talk on this in the SPARQL community there. the question is how do we solve this in the short term.
* TB: short term could be: Change the language.
* KK: I have two directoins: 1) define different content-type for the subset different content management 2) review if we can actually go with requirement that there is a conflict more than one hit. Is it possible that we don't actually need that mechanism. If we don't have it.. it'll be easier to have something that will be not too departing from SPARQL.
* TB: you're saying we should avoid using .. how weould it work then?
* KK: You need to get the resource that you're modifying.. and need to have DELETE DATA and INSERT DATA are triples not triple patterns. in that case you ca nbe confident that you have 0 or 1 hit.
* TB: if DELET EDATA just has a triple.. you mean explictly, x,p,13 .. yuou still cant' use that as a semaphore
* KK: If you delete that triple that's not in the data?
* TB: it will ignre it?
* KK: that is something we can change without distrupting to omuch I think. that is a small change to a sPARQL engine.
* TB: Making consistent with SPARQL ignores conflict sometimes and doesn't.. more complicated for devs.. if we use different semantics it should be in the syntax. this part of the syntax says it only deletes one part of the triple.. that'd be crazy.
* KK: short is to use a content-type. see issue.

### Topic
URL:

* name: text

PROPOSAL: text
* name: +1,0,-1

RESOLUTION: text

ACTION: text