-
Notifications
You must be signed in to change notification settings - Fork 7
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
Rename 'WebID Profile Document' to simply be 'WebID Document' #20
Comments
/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. |
+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. |
-1 No to changing "WebID Profile Document" to "WebID Document" . Why? |
Digging for justification for |
Identifier and Document disambiguation is the overarching issue. In addition, on the discovery front: 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. |
Perhaps better to remove WebID completely here, as it's a (Profile?) Document which contains a reference to or description of WebID(s). |
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). |
/chair hat off
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.
Better discussed in #54 .
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:
|
Apologies for this: The term "discovered document" seems like it could have many uses. If the discovered document is/has |
We should leave "WebID Profile Document" as is. Changing it will not reach consensus, amongst other downsides. |
can live with this, it is in fact a document that houses an identity
this is the least controversial of all, imho, just saying that webid has a document because it is http -- a tautology
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. |
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 |
/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. |
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? |
/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). |
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). |
/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.
That's fair! Strong objection to keeping "Profile" noted. |
Strong preference for Stronger preference for just Document or Document describing/containing, or Dereferenced Document - but appears that won't pass - so noting for posterity only. |
/chair hat on So far we have:
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. |
Correct, I see no value in taking "Profile" out, especially when that's exactly what the document is. Marriam Webster dictionary definition excerpt.
|
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
<#20 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB4LA2ZCRQ5HH3KOKJFLR3YW55IZAVCNFSM6AAAAAA26EJMY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRG42DEOBVGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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 |
fwiw, personally 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. |
I just noticed that this issue is still Open, so I'll just throw in my 2cents too: Strong preference for |
Proposal here is to recommend a ‘spec’ change to remove the word ‘Profile’ when referring to a ‘WebID Profile Document’.
Justifications
The text was updated successfully, but these errors were encountered: