Skip to content

Latest commit

 

History

History
120 lines (90 loc) · 9.01 KB

2022-08-23.md

File metadata and controls

120 lines (90 loc) · 9.01 KB
Raw

W3C Solid Community Group: WebID Profile

Present

  • Virginia Balseiro (VB)
  • Jeff Zucker (JZ)
  • Sarven Capadisli (SC)
  • Timea Turdean (TT)

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

Scribes

  • Sarven
  • Timea

Topics

Separation of index content

URL: #43

  • SC: I haven't reviewed.
  • JZ: Timea, as the primary author of the type index materials should decide roles/responsibilities for new type index spec
  • SC: I wasn't aware of how 'materials' are assigned. I thought the discussion that the PR is pointing to had to do with the separation - which is fine generally - but my concern was having a dedicated editor and/or author ( #35 (comment) ). Ruben said he can edit temporarily but that doesn't quite address the main concern. The PR includes the same editors as webid-profile. Was that intended or previously agreed?
  • TT: I did a cut/paste move and didn't dare to remove anyone because I thought that'd be seen as rude of me. That's all there is to it. We haven't decided if Ruben can be whatever role. I just thought it'd be rude to leave the current editors.
  • JZ: I don't think you need to feel responsible. You should have a say. Personally, I'm glad to contribute to the type index spec but not interested as an editor. So you can remove mine.
  • VB: You can remove mine as well but I'm here to help as well. And continue to help out as contributor aside from editors. Whatever you think is best.
  • TT: I just remove your names from editors to contributor. That's more appropriate than removing completely. Given the circumstance, then I can invite Ruben as editor? (the others noted)
  • SC: Either way is fine. Main thing is really just having committed editor(s). So at the moment, TT is the only editor, correct?
  • SC: No preference on 1 or 2 editors.
  • TT: Is publication of typeIndex spec dependent on WebID spec -> do they need to be published together?
  • JZ: My opinion is, especially Ruben's explanation on the PR, these should be orthogonal specs. The type-index should depend on the webid-profile. We should get the webid-profile spec out as soon we can.
  • SC: Well, webid-profile is already "out". The next release of webid-profile will not include if the separation goes through and by that point, we can also publish the type-index(es) spec in parallel.
  • JZ: We should not remove it from this doc?
  • SC: just have a reference on the webId spec. I wanna say it forma. different point of view. There is no pressing need to pull it out of that spec.
  • JZ: you are wrong
  • SC: you can add to it, it will look just fine. But someone needs to look after it. Design is fine, discovery of index... copy paste in the other doc is completely fine. As a reference you need to say nothing changes.
  • JZ: No. i would need to write discovery code and introduction if I do not talk about it.
  • SC: i did not say 'not talk about it'
  • JZ: lets look at issue 43 because that's what it says.
  • SC: you can still achieve what's intended (not talking about the changes) without splitting the docs. If we go ahead with the separation (which is ok too) that is going to require a different set of editors and commitment.
  • JZ: I thought we just decided above (Timea editor, we contributors...)
  • SC: then the reference .. should be no problem to publish at the same time.
  • JZ: but there is no NEED to publish at the same time
  • SC: this means, next release of webId profile is not going to offer any mechanism for type index...
  • JZ: looking at issue 43 - the spec should be completely orthogonal, webID spec should not depend on the index spec nor should we say if you want this go look at type index. But instead add it to otherPredicates... this spec defines type index but in the future there will be more... ex: indexes or interoperability. We are not going to say specifically about type indexes in our spec.
  • TT: okayed it.
  • SC: how much needs to change for this PR and for other separate PRs in the future (needs to be assessed)
  • JZ: please read my comment 'i withdraw my objections..'
  • SC: that is fine
  • TT: I agree with that too. I have a follow-up. Since it is clear to me on who edits and what needs to be done. But I want to ask you SC when is the appropriate time to create its own repo since that's where we seem to be going. When is process wise the right time?
  • SC: I suggest processing the PR as usual. Have the separation. Follow-up with a repo for type-indexes, set it up with GH Pages and so on.
  • TT: separate concerns - the comment about how to reflect this in the webID profile spec should be a separate PR.
  • JF: Ok, I will take care of that.
  • SC: we can separate it entirely, make a dedicated repo for it.
  • SC: Related question: would there a concept/name that's overlooking all this work? What would be the name if it were to be a panel? Now we are getting into specific repos for specs - this is fine. We need to find a way to reference all these.
  • JZ: eventually there will be specs for individual profiles and organisational profiles. As related... I do not know how this fits in. Each will have dedicated repos... but try to thing of as same.. Each spec should do that.

ACTION: Have RV clarify committent to type-indexes.

ACTION: TT to follow-up on PR, copy the type-indexes document into its own repo. Remove type-indexes from webid-profile repo.

ACTION: JZ to update webid-profile, removing type-indexes.

  • TT: re earlier question, it is to be seen what the name will be, maintained, managed and who is part of it. Too soon to say.

Proposed Conformance Model

URL: #40

  • JZ: The main difference between this conformance model and what we've been talking about is, I've included how ESS does it. Not to accommodate ESS but ... after conversation with AC, the webid document needs to be separate. We need to support the situation in which the IdP does not allow writing to the WebID document. If you get to the profile either it is a solid profile or pointing to a solid profile, and that document follows the rules. Has to have the predicates etc. This way the Solid profile is the same on servers but the diff being where the webid points to. If it is controlled by idp but not writeable but then needs to have a link to a place where it is writeable. In the NSS case you go straight to the profile. In ESS you go to another document. There are very few rules on the webid but more on the solid profile document.
  • SC: I'm a bit confused. I need to read the issue and proposed changes to be honest. Decision is up to you anyway.
  • SC: I suggest have others respond in the issue before moving on to a PR.
  • TT: we have a response from Trinpod: https://gitter.im/solid/specification?at=62fbd16ab16e8236e3dd5583
  • JZ: we also had a very good response from Pete Edwards (Issue #41)
  • SC: get people to respond on github issue/pulls. At the end we are going to look at this. So that it is not a suspire - was it a community agreement or..
  • TT: Question to JZ, I suppose all this mentions the type indexes that should change?
  • JZ: I've done that. Haven't uploaded yet but that's part of the process of removing type-indexes. Taking out of the conformances and other places that's mentioned.
  • TT: To some up this point. Have a last okay from contributors like Tim?
  • SC: No. Have Tim and others, including us comment on the issue.
  • VB: I will add my comments.
  • SC: it is a loose agreement only, if they are committing - you will have a reason why they should implement it. They will pull the spec in different directions, this can happen, until you ask them if they are willing to implement it.
  • JZ: I asked Aaron to comment on it too.

ACTION: JZ, VB, TT to invite others to comment on issue.

Document know privacy issues with Type Indexes and Trusted Apps

URL: #16

ACTION: JZ to respond to issue

  • JZ: Done.

ACTION: Revise the SHOULDs in the type indexes on when an app wants to make data public/shareable.

  • JZ: This belongs in the type index spec, should be moved there.

ACTION: Review with Tim on trustedApp

  • SC: TODO?
  • JZ: We need input on the conformance model, the separation of the type indexes, and the trustedApp .