Rename 'WebID Profile Document' to simply be 'WebID Document'

[nicolasmondada]

Proposal here is to recommend a ‘spec’ change to remove the word ‘Profile’ when referring to a ‘WebID Profile Document’.

Justifications

• Mainly because it's easier to say(!) and type in code or documentation.
• It removes any confusion with the 'extended' webid profile. Every time we explain WebIDs to someone we need talk about 'THE' profile and the 'extended' profile, adding even more cognitive burden to those learning about Solid.
• It would be consistent with related forms of usage - specifically 'Client ID Document' and 'DID Document'.
• Continuing to use ‘Profile' is overly limiting in terms of what we can expect to be contained in this document (i.e., whatever is in there kinda needs to be ‘Profile-like' data, which I assume may not always be the case (i.e., any user should be able to choose whatever they want to put in there - Profile-like or not)).

[jacoscaz]

/chair hat off

As we finally get to update the working draft, we seem to agree on using the concept of Extension Profiles from W3C's note on spec variability to identity the class of specifications building upon the "core" WebID spec.

IMHO, having both Extension Profiles and Profile Documents would be rather confusing. I'd be in favor of changing to WebID Document or even Identity Document (without the WebID prefix) as suggested by (I think) @woutermont a while ago.

[webr3]

Identity Document

+1 to this.

It is important that WebID works with things which exist or will be created, something modular that bolts on - as opposed to something fixed and standalone (for example having its own media type and strict rules).

Any language which facilitates an "augment this to your existing data" approach has to be a win.

[kidehen]

-1

No to changing "WebID Profile Document" to "WebID Document" .

Why? For starters, the term "Profile Document" is already in use across related specs.

[TallTed]

Digging for justification for discovery, I explored rather a lot of the Mercurial dump, and am amused to note that it flipped between "WebID Profile Document", "WebID Document", "Profile Document", and "Personal Profile". It's unfortunate that the dump lacks any surrounding discussion of why each of these changes was made.

[kidehen]

Identifier and Document disambiguation is the overarching issue. "WebID Document" doesn't disambiguate identifier and document with clarity.

In addition, on the discovery front: Given a WebID I can discover one or more clusters of other agents denoted by their respective WebIDs.

A WebID facilitates discovery of what ever it names in addition to what ever it's related to, by way of what's in its associated profile document.

Profiles are used in this manner outside of the Web, but without the expansive connectivity that HTTP facilitates. Unix even has a ".profile" file for similar purposes.

A you know, HTTP is heavily influenced by Unix. Keeping "Profile" in place is important and useful.

[webr3]

No to changing "WebID Profile Document" to "WebID Document" .

Perhaps better to remove WebID completely here, as it's a (Profile?) Document which contains a reference to or description of WebID(s).

[woutermont]

We already had a long discussion about dropping 'profile' in the Solid CG about a year ago. The main reason for doing so is because it is confusing: 'profile' immediately leads people to think about social media related personal profile pages. While a WebID Document might have been conceived as such, and has definitely been used to contain similar data, it has a much broader and more technical goal than merely being a set of personal profile data, i.e. it is an entry hook into the digital presence and toolchain of an agent.

The discussion in the Solid CG led to the use of two distinct terms: 'WebID Document' for the document a WebID dereferences to, and 'Solid Profile' for the set personal profile data discoverable from the WebID entry hook, including the WebID Document, but also the Preferences File and the Extended Profile. I personally believe this is a clear and workable disambiguation. Note that in this sense a 'profile' is a data boundary, not a document boundary, which precisely addresses one of @nicolasmondada's concerns.

The above is a semantic point. I also agree with the pragmatic one: we also use 'profile' in the sense of W3C Spec Variability; this makes the term ambiguous. We can easily resolve this ambiguity by dropping 'profile' from 'WebID Profile Document' since in the latter term it is redundant, i.e. everyone will still know what we mean when saying 'WebID Document'.

Re dropping 'WebID' (@webr3's proposal), I'm not in favour. Within the scope of the WebID spec and ecosystem, the document we are talking about is the document a WebID dereferences to, so 'WebID Document' is a good term. As @nicolasmondada already pointed out, when we look at specs with a similar behaviour, their terminology is the same ('DID Document', 'Client ID Document'). Only when we talk in a more general sense, I prefer to use the term 'Identity Document'. A WebID Document is then an Identity Document to which a WebID refers, a DID Document one to which a DID refers (and ideally, nothing should prevent those to be the same).

[jacoscaz]

/chair hat off

"WebID Document" doesn't disambiguate identifier and document with clarity

Personally I don't find this to be the case. Most importantly, I've asked a few colleagues that work in completely unrelated areas and they don't find this to be the case, either.

Digging for justification for discovery,

In addition, on the discovery front:

Better discussed in #54 .

Note that in this sense a 'profile' is a data boundary, not a document boundary, [...] The above is a semantic point

Good point.

There are no blockers for me, here, though I do think that Profile is confusing no matter what surrounds it. In order of preference:

1. Identity Document
2. WebID Document
3. Profile Document
4. WebID Profile Document

[webr3]

Apologies for this:

The term "discovered document" seems like it could have many uses.

If the discovered document is/has the discovered document must contained in the discovered document

[kidehen]

We should leave "WebID Profile Document" as is. Changing it will not reach consensus, amongst other downsides.

[melvincarvalho]

I think DID Document is a bad example of how to do identity.

While the diagrams look beautiful. No developer I've ever met understands the concept. Here was their attempt to clarify it in the spec:

[melvincarvalho]

• Identity Document

can live with this, it is in fact a document that houses an identity

• WebID Document

this is the least controversial of all, imho, just saying that webid has a document because it is http -- a tautology

• Profile Document

• WebID Profile Document

can live with either

but no one has ever really said what is the difference between a Person and a Profile, and also now we have extension Profiles, which we didnt before

Perhaps grammatically correct is the "WebID's document", with an apostrophe. But omitted for convenience.

Regarding Solid uses of WebID, it seems to have diverged a long way from what the purpose is, and that is a social identifier on the Web. Definitely "Solid Profile" is different from anything in WebID, and a branding discussion. WebID can be clean, simple, elegant and developer friendly.

[melvincarvalho]

-1

No to changing "WebID Profile Document" to "WebID Document" .

We should probably take this has a hard NACK for now, unless @kidehen might change his mind, or find a formulation he can live with.

If it's impossible to live with the status quo, we should try and find a better way. Otherwise probably best to move to other things that need doing such as extension profiles.

just my 2c

[jacoscaz]

/chair hat on

@kidehen is yours a hard no / strong objection / hard NACK to changing "WebID Profile Document" into "WebID Document" ?

Asking because, from what I can see, everybody else in this thread might actually be open to it or even prefer doing so. However, nobody has expressed a strong dissatisfaction with "WebID Profile Document", either. Ultimately, given the conversation above, making this change or not boils down to whether this is something you could live with.

[woutermont]

Come on, it's terminology, not an impactful technical change. If everyone except one person agrees that a shorter and less confusing term would be better, are we really going to base our decision on the preference of that one person?

[jacoscaz]

/chair hat on

@woutermont while I personally agree, I don't think that approach would go far as chair, at least based on the last few years of discussion. Presently I'm trying to ascertain whether there are strong objections at all.

If there were strong objections to both keeping and dropping "Profile", then of course I would have to choose which strong objection to go against and would do so based on where the majority stands. But, insofar as no strong objections are raised to keeping "Profile", I don't see the point of forcing the change through rather than settle for keeping "Profile", which looks like something we could all live with (if begrudgingly).

[woutermont]

What I'm trying to point out is that, as far as terminology goes, 'being able to live with' is quite relative. If personal preference is enough, then I hereby raise a strong objection. If not, then we can only look at (A) the number of advantages/disadvantages raised (which is in favour of dropping), or (B) the number of people in favour of an option (which is again in favour of dropping).

[jacoscaz]

/chair hat on

@woutermont I don't always find it easy to discriminate between personal preference and objective technical superiority, mostly because we each differ in our sensibility to technical issues based on our experiences and areas of expertise. The demarcation between A and B is not as clear, IMHO.

Generally speaking, my goal as chair is unanimity. If I have to settle for something less than unanimity, I aim for the solution with the largest consensus and no strong objections. If I have to settle for something even further from unanimity, I aim for the solution with the largest consensus and the fewest strong objections. That is why I always ask to clarify whether a NACK is a hard one or not, and why I tend to only do so after giving the conversation a chance to converge.

An exception to this rule would be something to which I personally object so strongly that I would rather resign than being the chair under which it were brought into the spec.

then I hereby raise a strong objection

That's fair! Strong objection to keeping "Profile" noted.

[webr3]

Any language which facilitates an "augment this to your existing data" approach has to be a win.

Strong preference for WebID Document over WebID Profile Document so +1 to removing Profile.

Stronger preference for just Document or Document describing/containing, or Dereferenced Document - but appears that won't pass - so noting for posterity only.

[jacoscaz]

/chair hat on

So far we have:

• 3 strong preferences for "WebID Document" over "WebID Profile Document" (@nicolasmondada , @woutermont and @webr3)
• 2 soft preferences for "WebID Document" over "WebID Profile Document" (@melvincarvalho and @jacoscaz)
• 1 strong (I think?) preference for "WebID Profile Document" over "WebID Document" (@kidehen)

Consensus seems to lie with "WebID Document", at least based on the preferences and the arguments put forth so far. Unanimity is unlikely but strong preferences have been expressed. I'll create a PR for this in the next few days.

[kidehen]

Correct, I see no value in taking "Profile" out, especially when that's exactly what the document is.

Marriam Webster dictionary definition excerpt.

..
: a set of data often in graphic form portraying the significant features of something
..

[webr3]

That's a hard sell, definition of document: a writing conveying information

On Wed, 6 Mar 2024, 20:39 Kingsley Idehen, @.***> wrote:

Correct, I see no value in taking "Profile" out, especially when that's exactly the document is.

Marriam Webster dictionary definition https://www.merriam-webster.com/dictionary/profile excerpt.

.. : a set of data often in graphic form portraying the significant features of something ..

— Reply to this email directly, view it on GitHub https://github.com/w3c/WebID/issues/20#issuecomment-1981742850, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB4LA2ZCRQ5HH3KOKJFLR3YW55IZAVCNFSM6AAAAAA26EJMY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRG42DEOBVGA . You are receiving this because you were mentioned.Message ID: @.***>

[kidehen]

The fundamental point here is that the term "Profile Document" isn't novel. It is in common use that serves the WebID Specification well.

SeeAlso, courtesy of Microsoft CoPilot: https://sl.bing.net/jZu2OGmxa5Q

[TallTed]

fwiw, personally WebID Profile Document > WebID Document > WebID Profile > Profile Document.

It's a Document, containing the Profile, of a WebID.

I think there may well be more than one document described by either of the latter labels, certainly the last; while there should, and will probably, be only one document described by the first label, for any given WebID.

[pmcb55]

I just noticed that this issue is still Open, so I'll just throw in my 2cents too:

Strong preference for WebID Document over WebID Profile Document - so +1 to removing Profile.