Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circumstances under which profiles are used or shared #52

Closed
10 tasks
csarven opened this issue Sep 27, 2022 · 9 comments · Fixed by #87
Closed
10 tasks

Circumstances under which profiles are used or shared #52

csarven opened this issue Sep 27, 2022 · 9 comments · Fixed by #87
Assignees

Comments

@csarven
Copy link
Member

csarven commented Sep 27, 2022

WebID identifies one within the space of social, conceptual, and contextual relations.

Where possible, the Solid WebID Profile specification should aim to provide recommendations; clarify and open the space for recommendations to be developed; waypoint to existing documentation; or include considerations for circumstances under which profiles are used or shared, e.g.:

  • Communication and use of multiple profiles for different purposes.
  • Connectivity of multiple profiles and cross-context recognition.
  • Cascade of profile information.
  • Persistence and evolution of profiles.
  • Anonymous and pseudonymous profiles.
  • Self-controlled and third-party-controlled identities.
  • Information for the purpose of verification, authentication, authorization purposes.
  • Compilation of preferences, choices, activities and interactions of an agent.
  • Social graph for different kinds of relationships between agents.
  • Factors specific to physical, physiological, genetic, mental, economic, cultural, social, or behavioural identity.
@jeff-zucker
Copy link
Member

As I understand it, I am writing the introduction covering some of these topics in a general way and @VirginiaBalseiro is writing the actual use cases. I'm almost done with a draft of a revised intro taking many of @csarven's excellent points into consideration as well as trying to do more of what @timea-solid has mentioned repeatedly - providing an overview for developers that helps them find the parts of this document they need to and explains why they might need the various parts of it.

@jeff-zucker
Copy link
Member

@csarven could you clarify what you mean by "Cascade of profile information" and
"Persistence and evolution of profiles"? Thanks!

@csarven
Copy link
Member Author

csarven commented Oct 28, 2022

As mentioned above and meeting, it is the kind of information that needs to be massaged throughout the specification, and not only an overview about it in a specific section (like the introduction). There is a high overlap between the use cases and the considerations above, so I suggest covering it in varying ways.

@jeff-zucker
Copy link
Member

Agreed. I meant only that the intro and the use cases are current action items. We will also need to revise other sections later.

@jeff-zucker
Copy link
Member

And my understanding of the split in work between Virginia and I may be wrong. @VirginiaBalseiro if you would prefer to take ownership of the introduction, I'll just pass you my notes and let you proceed.

@VirginiaBalseiro
Copy link
Member

VirginiaBalseiro commented Oct 28, 2022

@jeff-zucker No, but perhaps it might be useful to finalize the use cases and scenarios before including them in the intro., just to prevent unnecessary work/efforts duplication.

@jeff-zucker
Copy link
Member

Okay, great, I will consider only the writing the intro part as the part of this issue assigned to me. And of course it will only be a draft with expected changes from you and others.

I had thought that the use cases would have a separate section of their own and that the intro would be much more general and refer to that section. Do you see the use-cases as actually being part of the intro? If so, fine, but I would think that you will need a greater level of detail about how the whole profile is set up before getting into use cases so I would see it as towards the end of the spec. If you disagree, please let me know, I'll work around whatever way you want to do it.

Agreed - we'll definitely need to check that the two sections (if we end up with two) are in sync before finalizing.

@VirginiaBalseiro
Copy link
Member

I think use cases should be either its own section or a separate document, but we can decide when we have a text. I will PR to /notes (most likely) soon, and we can take it from there.

@jeff-zucker
Copy link
Member

Okay, sounds like we're on the same page there. I'll also PR mine (I guess to notes) soon and we can work out kinks from there.

@jeff-zucker jeff-zucker removed their assignment Oct 28, 2022
jeff-zucker added a commit that referenced this issue Nov 4, 2022
To replace current introduction and also current "other predicates" section in line with #52 and @VirginiaBalseiro 's suggestion to split off best practices and use cases
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants