Discussion/input/suggestions on how to work on this repo

[timea-solid]

On this ticket we want to collect ideas sparked in conversations or implementations... feel free to add yours. This spec is for now only documenting the 'as-is', however we should not forget 'might-become' ideas too.

This discussion is inviting to debate the ways we are working on this repo. All conclusions will be documented at the end on the README.

[woutermont]

@timea-solid, just wondering: why are these ideas not in separate issues? Or in discussions, which by default come with an 'idea' category?

[jeff-zucker]

bulb -> the profile name available via the standard discovery mechanisms, for example via the Type Indexes (instead of having it in the Solid WebId profile directly). as mentioned on the webId-profile gitter chat

As I understand it, it is not just the name that Wouter is concerned about, it is everything he labels "social media profile data". I find it a horrible idea to remove them out of the main profile. If we end up having to accommodate the second hop on from the WebID Profile to the Solid Profile, this would mean that an app would have to go through three hops to even get a person's name, friends, communities and other data which belongs, in my opinion front and center in the profile.

[jeff-zucker]

bulb-> have type indices separated per pod. For instance, if I have a Pod for all of my financial data and a separate Pod for my fitness tracking, I wouldn't want the type index for the first pod inside the second pod -- I'd want two separate type indices, based on two separate Solid Profiles as mentioned on the webId-profile gitter chat. and also here

The idea of multiple profiles per WebID is interesting. We decided in one of the past meetings that on @timbl's suggestion we stick with one profile per WebID for now and perhaps tackle the more complex issue of multiple profiles per WebID later. One serious problem with multiple profiles per WebID is - how do they share anything in common e.g. a public profile with an inbox and three sub-profiles with inbox all four accessible by looking for <?WebID> ldp:inbox where WebID is the same for the main profile and the other three.

The idea of multiple type indexes, however is much easier to handle - there is no problem if there are duplicates, one could easily load type indexes from the main profile for public stuff and then additional app-based type indexes too. If we could store type-registrations in seeAlso files, we could have multiple seeAlsos, each permissioned for a different app. This would not, AFAIK impact anything else but would solve a major complaint of the interop group that any app can see the type registrations of any other app.

[timea-solid]

Ok, I have to stop the discussion right here @jeff-zucker and @woutermont. Since this repo does not 'yet' have a discussion feature I wanted to make sure we do not forget about these ideas. Also, to answer the previous question: with the clear structure above-> I wanted to avoid ANY discussion on these future ideas because the priority right now is to write the what-is of the Type Indexes. I personally believe we should (nor do I have time) digest and get into debates on what there should be in the future, at this point. That being said: I cannot stop people who do want to debate future ideas and specs. These debates can be used later, on the next version of this documentation -> hence -> feel free to open issues and discuss away (label as discussion and future iteration please). Of course, if the discussion is on current matters of Type Indexes and not future ideas then we will need a collaborative and friendly discussion preferably in meetings.

[jeff-zucker]

Agree, I understood this as a place to jot down thoughts for future exploration, not to put additional tasks on the current draft.

[woutermont]

[W]ith the clear structure above-> I wanted to avoid ANY discussion on these future ideas because the priority right now is to write the what-is of the Type Indexes.

That's what I thought, which is why I asked for separate issues/discussions instead of taking over this one 🙂

I personally believe we should (nor do I have time) to digest and get into debates on what there should be in the future, at this point.

I think we should, though, since that's what's going on: people in the ecosystem are thinking and talking about the best way to do data discovery.

These debates can be used later, on the next version of this documentation [...] label as discussion and `future iteration'

Do you characterise this proposal as a documentation of the current use of type indexes? If so, why does it contain normative text? If not, why would well-argumented proposals not be considered for inclusion in the current version?

---

@jeff-zucker, without in any way devaluing the content of your specific comments, could you maybe hide them, in order to retake them in specific issues/discussions?

[timea-solid]

I hear both inputs. Thank you.

To try to have a structured discussion with follow-up actions:

• I changed this ticket into a discussion on how to work on this repo;
• there is now an overview of idea collections here;
• feel free to open up a discussion on your ideas as is this and label it with discussionand future idea so the next editors can start from there for next version.

Do you characterise this proposal as a documentation of the current use of type indexes? If so, why does it contain normative text? If not, why would well-argumented proposals not be considered for inclusion in the current version?

@woutermont please open a separate discussion ticket for this additional topic.

I asked Jeff to create separate discussion tickets for his comments.

[jeff-zucker]

Do you characterise this proposal as a documentation of the current use of type indexes? If so, why does it contain normative text? If not, why would well-argumented proposals not be considered for inclusion in the current version?

Specification writers can not know in advance whether what they are writing about requires normative text, it is part of their job to find that out . If someone writes something normative you don't agree with, object. If someone submits a document which you don't think is a spec by your definition, object. But you can not demand that the authors of the document tell you in advance what they will be saying.

If not, why would well-argumented proposals not be considered for inclusion in the current version?

Because the community has existed too long without these topics being covered in an authoritative way (whether normatively or not) and getting a spec out the door is a high priority. You are welcome to submit "well-argumented proposals" in the next draft of the spec. This doesn't just apply to you, I just proposed something issue #2 and Timea put a "future idea" tag on it. I'd love it to be in the current draft but recognize that putting it up for future consideration is the best choice at the moment.

[woutermont]

@timea-solid, thanks! My first suggestion for easier conversations would be to open up the GitHub Discussions tab, if that is possible.

---

@jeff-zucker

Specification writers can not know in advance whether what they are writing about requires normative text

Well they should. When you start writing a document, you have a goal. That goal can be of the form "let's describe how things are done" or of the form "let's say how things should ideally be done." I'm not demanding impossible efforts like reciting me the future text of the document. What I am asking is which of the two is the goal of this document.

[T]he community has existed too long without these topics being covered in an authoritative way [...] and getting a spec out the door is a high priority.

So we're cutting corners because all the stuff that works should be confirmed as being correct as soon as possible? There are companies and government agencies eagerly awaiting SAI for almost two years; does that mean that we should ship it without thinking about compatibility with current apps? No, we tell them it will be ready when it is ready, and we make do with parts of it for now. Luckily I might soon be able to go to them with a new answer: SAI is ready, it stopped bothering with compatibility, since the people to be compatible with don't bother either; although, then I could as well advise them to let Solid go.

[woutermont]

Sorry @timea-solid, couldn't help but react to @jeff-zucker. I've hidden my comment as off-topic. @jeff-zucker, if you want to react to it, maybe you better do so in a new issue or in Gitter.

The one constructive part of it was: my first suggestion for easier conversations would be to open up the GitHub Discussions tab, if that is possible.

[jeff-zucker]

Yes, I likewise hidden everything of mine that was a comment on another suggestion because this issue is for listing issues, not discussing them,