[Enhancement] - Update naming for Civic Profile and/or Profile

[leekahung]

Describe the Current Behavior/Feature:

At the moment there is quite a bit of confusion about the differences in Profile and Civic Profile due to the wording, but I think I have a solution to this. We could have "Profile" be changed to "Account" and "Civic Profile" be changed to "Profile" proper.

[Update 12/09/2023] - Other naming conventions could be used as well to make the two distinct. Several other ideas has been proposed such as:

1. convention for things associated with webIds like "user menu/user settings"
2. utilize alternative wording such as "account"/"settings"
3. utilize prefix words like "Pod" or "PASS" to associate profiles like what's done with "Civic Profile"

Rationale:

To clear up what we have now with regards to user information and account information.

Proposed Implementation (if applicable):

For this implementation we could simply rename the pages and routes accordingly.

[xscottxbrownx]

@leekahung - how far do you want to go with this one?

I started, and it just kept going and going.

Do we just want to change anything user facing to Account/Profile, or do we want to change everything?

Doesn't matter to me either way, but if we want to change all functions and objects and such, then I'll go about this a smarter way and commit a component, a util function, etc at a time.

[leekahung]

Do we just want to change anything user facing to Account/Profile, or do we want to change everything?

Doesn't matter to me either way, but if we want to change all functions and objects and such, then I'll go about this a smarter way and commit a component, a util function, etc at a time.

Think we could see how far it'll go first. If the PR gets too big, we can split it up then.

[timbot1789]

I think part of the issue here is that the data in the public profile comes from the WebId, which is used by virtually every Solid app. Giving a distinct name to it may be confusing to some people using several different solid apps. The Element program, which is a client for a decentralized chat protocol called matrix, has a similar identity issue. They use terms like "user menu" and "user settings" for info analogous to the WebId. Maybe we could do something like that?

I think just calling the civic profile "profile" is a bit too vague. It doesn't communicate the information that's contained in the document.

[andycwilliams]

Agree with Tim. I hesitate deviating too much from what's already commonplace. Maybe simply change Profile to Contact Profile (while also changing Profile to Account)? That would make a clearer connection to the Contacts section. I have no definitive stance on this at the moment.

I'd like to get some feedback from caseworkers with this and see if any versions are more intuitive than others.

[leekahung]

Pretty open to making the two entities distinct with naming. Think we just need a consensus on those name.

[leekahung]

For what we have now as "Profile", I'm thinking we could perhaps prefix it with Pod, so something like "Pod Profile/Account/Settings/Menu". It'll help users associate the information there with their Pod specifically.

For "Civic Profile", think we could still use the name "Civic Profile". Though the Element example with "User" sounds pretty good too, so something like "User Profile". We could also use something like "PASS Profile", which associates it with PASS specifically.

[xscottxbrownx]

Well, then I will stop at the 4hrs put into this already until this convo is hashed out.

[timbot1789]

For what we have now as "Profile", I'm thinking we could perhaps prefix it with Pod, so something like "Pod Profile/Account/Settings/Menu". It'll help users associate the information there with their Pod specifically.

For "Civic Profile", think we could still use the name "Civic Profile". Though the Element example with "User" sounds pretty good too, so something like "User Profile". We could also use something like "PASS Profile", which associates it with PASS specifically.

The Element example is in reference to what you called "Profile" or the web ID. "Pod profile" is inaccurate because the web ID is on a higher level than the pod.

"PASS profile" and "User Profile" are a bit imprecise as well. The data isn't PASS specific, it's intended to be shared with other groups. User Profile doesn't convey that the data is confidential and important for legal purposes. It can also be easily confused with the WebID.

The questions here are:

• What is a good name for the WebID that conveys its purpose to the user in a clear and friendly way?
• What is a good name for the object we store HMIS data in that conveys its purpose to the user in a clear and friendly way?

I don't have a strong opinion on the answer to question 1. Maybe something like "user settings" or "ID settings." I think "civic profile" is a good answer to question 2.

[timbot1789]

We also don't need to allow editing of the web ID. It's not a core feature of the app.

[leekahung]

The questions here are:

• What is a good name for the WebID that conveys its purpose to the user in a clear and friendly way?
• What is a good name for the object we store HMIS data in that conveys its purpose to the user in a clear and friendly way?
  I don't have a strong opinion on the answer to question 1. Maybe something like "user settings" or "ID settings." I think "civic profile" is a good answer to question 2.

I'm kind of leaning towards:

1. "Profile" -> "User settings"
2. "Civic Profile" -> unchanged

What do you guys think @xscottxbrownx @andycwilliams?

We also don't need to allow editing of the web ID. It's not a core feature of the app.

I think limited editing to the web ID profile card should be fine if it's just the name, nickname, profile image, and maybe e-mail. It'll allow users to create a simple public profile card on PASS like what we have on GitHub/Twitter and mostly just for that purpose:

More detailed personal information for things like Legal Name, Date of Birth, etc would be locked behind "Civic Profile" and could be requested. Was thinking perhaps something like a button appearing in /contacts/:webId that let's users see the other person's "Civic Profile" in a route /contacts/:webId/civic-profile if permissions were given to them

[xscottxbrownx]

I have a few questions before I can discuss/give any more opinion.

1) I was under the assumption the WebID was the url link - basically like an email address.

• Is that completely incorrect?
• It seems in this discussion that the WebID might be more like a profile page in solid?

---

2) To be able to give opinions on names, I need to understand why we need 2 different "profiles" in the first place. Also what they are ultimately going to hold, who will have access to the info held, and how these will be used.

• If it's just public data & then private data... then just 'public profile' & 'civic profile' ?
• I think I need to understand better who and where a user can see another's info from the current Profile (in this PR as Account) info. Is it just a PASS thing only, if so - is there any reason to not just use legal info?

---

3) Now it seems there is a discussion starting if we need to have the image and names be able to be edited.

• This functionality has been in place for like 5 months - why is this just being brought up now?
• It's had multiple PRs involving it.

[leekahung]

1) I was under the assumption the WebID was the url link - basically like an email address.

• Is that completely incorrect?
• It seems in this discussion that the WebID might be more like a profile page in solid?

Kind of both? There are distinctions between a WebId and a WebId Profile (see spec on Solid WebId profile, https://solid.github.io/webid-profile/ , which mentions a unique URI for the user in question, and reference link to an example under section 2 Discovery of the spec for WebId Profile Document: https://www.w3.org/2005/Incubator/webid/spec/identity/#dfn-profile_document). But essentially, one could update the WebId Profile (https://<server>/<username>/profile/card) like an RDF file, which is what we're doing with the profile name, nickname, and profile image, but the WebId URI (https://<server>/<username>/profile/card#me) itself would remain be unchanged (this is analogous to the email example).

[timbot1789]

1. I was under the assumption the WebID was the url link - basically like an email address.

The wording here is confusing, and the email address analogy is a simple one for people just getting started.
The Web ID is a combination of a URI and a profile document. The WebID URI points to the profile document. The contents of the profile document are defined by the Solid Spec and are used to power identity in solid applications. If a WebID profile document does not comply with the Solid Spec, it cannot be used in solid apps at all. That means, that if an application incorrectly edits a web ID and breaks it, the user can no longer use the Web ID to access their pod.

2. To be able to give opinions on names, I need to understand why we need 2 different "profiles" in the first place. Also what they are ultimately going to hold, who will have access to the info held, and how these will be used.

One profile is the web ID profile. The other, "civic profile" contains structured data about yourself that is useful to civic groups.

We don't control the Web ID. The WebID is largely public, and is touched by virtually every solid app a person will ever use. It is also used to access a person's pod. Its structure and contents are also defined by the solid spec, and enforced by the solid server. The web ID is not stored in a pod, but is managed by the Solid Server. Multiple web IDs can access a Pod, and many pods can be accessed by a single web ID.

We fully control the civic profile. The Civic Profile is mostly private. It should only be shared with certain other agents of the user's explicit choosing. It won't be generally touched on by other apps; only apps in the same domain as PASS would be interested in it. Since the Civic profile is a data model of our own creation, we can define its structure and contents as we see fit (we're mostly applying the HMIS OWL ontology). The Civic Profile is stored in a person's pod, and the solid server doesn't treat it any differently than any other file stored there.

3. Now it seems there is a discussion starting if we need to have the image and names be able to be edited.

These issues were raised in the comments of every PR. It's an inherent problem with the feature itself. If our understanding improves as we build the app, and we determine that the problems of a feature outweigh its benefits, it may be removed. See 1. for one of the issues with apps editing web IDs.

It also helps from time to time to flip an issue upside down and see if interesting things fall out. If we don't implement editing of the WebID in PASS, we don't need to expose a concept of a "profile" at all. We can still display the card, with their profile picture on it, but we can assume that's uploaded from a different program. Or maybe we still allow editing of the WebID, but we never provide a name for it in PASS itself. Internally we refer to it as the WebID, but we don't expose that name to the end user unless we have to. Then the problem of how to distinguish between all the different profiles is moot. There are no different profiles.

[leekahung]

Was thinking we should just call "Profile" as "Account" and "Civic Profile" as "Profile". The discussion had been open for a while, but there's still quite a bit of confusion over the two entities. While "Profile" might sound somewhat vague, I think naming the two with separate wording would give them a bit more distinction.

If not "Profile"/"Account", we could add a bit more distinction with an additional word, "Civic Profile"/"Pod Account" or "User Profile"/"Pod Account."