Social url/handle separation
jayzalowitz opened this issue · 59 comments
Take it from me, unless you have a handle/id (ex FBid)/standardurl setup its going to lead to issues.
i would suggest
ex:
twitter_url: https://twitter.com/handle
twitter_handle: @handle
twitter_id: twitterApiId
This allows for both handle referencing, linking, and API integration
Adding a bunch of keys like that is not nice. But I agree that you will indeed run into problems.
This would be more of my liking.
{
twitter: {
handle: "handle", /* no @ please */
url: "https://twitter.com/handle",
...
}
}
However, what would be the canonical form for new profile types? id?
{icq: {id: "12345"}}
In that case we should name the twitter handle (@handle) id as well.
And the facebook username should also be id.
Or we could call all of them handle, but that would make the icq num improbable.
How about pk for primary key: use the friendliest unique key:
- for facebook, the username is unique and most readable (preferable to the fbid)
- for twitter, the handle is unique and ...
- for icq, the icqnum is unique (and not readable)
Going back to the example:
{
twitter: {
pk: "handle", /* no @ please */
url: "https://twitter.com/handle",
...
}
}
I think pk makes progress on the issue. Other issues have brought up that dynamic property names are inconsistent with most of the specification also and instead we should maybe favor
{
name: "twitter",
pk: "handle", /* no @ please */
url: "https://twitter.com/handle"
}
When people use "twitter.com" instead of "twitter", I'm hoping themes will push certain names to become standard.
I get the idea of using the phrase pk, I really do, but for most social networks there is a distinct identification difference between numerical id, which never changes, and handle, as well as url, my suggestion is to just call that the id as it is more normally understandable
@jayzalowitz : I'm not sure what you're saying.
- Yes, there likely is an unchanging id (facebook has
fbidand twitter probably has something similar). - And no, I don't want people to put that id in there. Hence the choice for a different term which is unused (unlike id/handle/nick): pk.
- The requirement is not that it is immutable, only that it is unique and preferred for human consumption.
I don't think there's a use for including a numerical, technical id (like the fbid). The two things I would be interested in, are: something like a handle (Twitter handle, FB pretty-username) and the profile url. What remains, is naming those two.
I think pk is not going to be clear for a lot of people. Why not call it userId?
I distinctly disagree, on the nonchanging,stable id front. As someone who has just gotten done building a service around social information and job candidate, I can tell you it is of incredible importance to have both proper linking and programmatic + perm. access to reach out for more information.
The best example is tools can be built to keep a resume up to date using these profile ids, and with how portable this is supposed to be that would mean people never really having to update a real resume again.
That being said, I agree that userID > pk for multiple reasons
But what are you saying? Aside from userId (for handles etc.) and url, should we add the technical id as well? I think people should update the userIds in their resume.json, if they change handles etc.
Yes, It is a really big deal for me to make sure there is a technical id in
the spec.
There are no changes in the fbid... twitterid.. for example they stay the
same number and can be used to fetch more information reliable no matter
what the user does with their account. Additionally, they are the only
field guaranteed to be there in some cases. (ex;basic calls to facebook
without auth.)
My understanding, which may be wrong, is that twitter teats the id as the
key if finds information off of in their api.
Think thats not important? What about a tool that tracks social media
manager applications by the number of followers they have, that would have
to have the unique id built in.
I pointed this out somewhere else, but many Facebook users do not have usernames, so their URL uses their ID instead. In addition, many LinkedIn users do not have usernames, but instead only have ID's (internal to LinkedIn) and unique URLs for public consumption. There are other services out there that try to give all their users usernames, but as it turns out, usernames are not enforced across their userbase. These might be edge cases, so maybe they shouldn't dictate the default schema label, but there should definitely be a fallback at minimum for people who don't have usernames.
Also, has "handle" become a universal term now? Is that preferred over "usernames"?
So correct me if I understand, but the current choices are:
- handle
- username
- pk
- primaryKey
- id
- userID
The pk choice was the only one in the list that I needed to look up to know what it meant. Due to its lack of clarity, consider removing or renaming it.
I changed it to include another choice "primaryKey" - also added "id".
I honestly feel like userid or id makes more sense than pk, thats just me.
I don't think I have seen that in a spec anywhere, and if you aren't as
familiar with relational databases, it really dosen't make as much sense.
On Thu, Jul 10, 2014 at 1:05 PM, Ryan Shea notifications@github.com wrote:
I changed it to "pk (or primaryKey)"
—
Reply to this email directly or view it on GitHub
#6 (comment)
.
@jayzalowitz, I'm with you on this one. Even seeing it with the definition, it is the least intuitive. Let's get rid of it.
-1 for pk
I agree, I'm not a fan of pk. Just including that in the list of choices so other people joining the conversation have context.
That makes sense.
Nit: For the sake of sanity, please keep comments rolling forward rather than editing old ones (unless it's within moments of posting).
Experimenting with a new label called "Decision Needed", this issue has it applied. It means we will be passing something through in the very near future.
I vote for any of these: "username", "userId"
Also, #71 deals with social media as well, and as I said there: I think we should enforce that either username/userId is provided or url and optionally both.
Well, username is so common and standard, why even discuss odd alternatives such as pk (99% of non-tech people don't know it) or id (too unspecific). I think there are more important decisions to make ...
Still the choice between userId and username. And you know, there are 2 hard things in computer science (and anything else really): cache invalidation and naming things.
Yes, these two are actually interchangeable, at least in common parlance. I think we can be happy with both of them ;)
I vote for
Link
UserId
Username
There is a real need in some of the apps I have personally built in the
employment space for said unique userid that does not change.
Take it from me, a UserId as described in the sentence above is present in
the APIs of just about every social network, and if we don't account for
it, people doing the social thing may be a lot less likely to use this (I
cannot describe how much it helps with the amount of error checking and
lookup code you need to write.).
On Fri, Jul 11, 2014 at 5:58 AM, Daan Debie notifications@github.com
wrote:
Still the choice between userId and username. And you know, there are 2
hard things in computer science (and anything else really): cache
invalidation and naming things.—
Reply to this email directly or view it on GitHub
#6 (comment)
.
Eeeehm, I think we're talking about userId/username for specifying your "handle", not the unique number that Twitter/Facebook/... uses to identify someone.
I still think a "technical id" should not be included. Adoption will actually be hampered if people have to lookup this number to complete their jsonresume.
Take it from me,
I'm sorry if I don't just "take things" from people on the internet :)
and if we don't account for it, people doing the social thing may be a lot less likely to use this
Baseless assumptions as far as I'm concerned.
Should it be required. No. Should it be in the spec so that if people want
to pass those unique ids on they can be. yes.
Scripts can be written to fetch said Ids when a "normal person" puts in
their username (which btw, should be the name for that)
On Fri, Jul 11, 2014 at 6:39 AM, Daan Debie notifications@github.com
wrote:
Eeeehm, I think we're talking about userId/username for specifying your
"handle", not the unique number that Twitter/Facebook/... uses to identify
someone.I still think a "technical id" should not be included. Adoption will
actually be hampered if people have to lookup this number to complete their
jsonresume.Take it from me,
I'm sorry if I don't just "take things" from people on the internet :)
and if we don't account for it, people doing the social thing may be a lot
less likely to use thisBaseless assumptions as far as I'm concerned.
—
Reply to this email directly or view it on GitHub
#6 (comment)
.
That's nice and all, but social networks also allow you to fetch users by their username. And if that's not present, the url will always contain some sort of id to identify the user.
If you make it optional, its perceived value becomes even less, because what use are your machine routines if you cannot depend on each user having it?
Regardless, I still vote -1 on adding a technical id.
Maybe others should chime in!
Daan,
That's nice and all, but social networks also allow you to fetch users by
their username.
Usernames can and do change, thats why I am suggesting this.
And if that's not present, the url will always contain some sort of id to
identify the user.
is so incorrect that you dont even know... it 100% depends on what security
restriction on viewership the network is trying to impose
If you make it optional, its perceived value becomes even less, because
what use are your machine routines if you cannot depend on each user having
it?
Actually, one of the big deals here is limiting api calls to the service
under limited conditions... and to add a point, you cant actually rely on
the username input being correct anyway.
Point being, without this feature in there, this spec requires a large
amount of api unique id tables and that sort of thing stored outside of
this system, when having an optional field could prevent a lot of extra
issues.
On Fri, Jul 11, 2014 at 7:11 AM, Daan Debie notifications@github.com
wrote:
That's nice and all, but social networks also allow you to fetch users by
their username. And if that's not present, the url will always contain
some sort of id to identify the user.
If you make it optional, its perceived value becomes even less, because
what use are your machine routines if you cannot depend on each user having
it?Regardless, I still vote -1 on adding a technical id.
Maybe others should chime in!
—
Reply to this email directly or view it on GitHub
#6 (comment)
.
The old-school approach is if I change my username, I vet my resume for accuracy before I send it out.
Does this issue need to be decided for v1; as per the title of this issue, can we use either a URL or a handle for v1?
Proposal: each social network account is specified with a username and a url. At least one of those is required, specifying both is optional.
Please vote.
+1
Great points everybody, this is a tricky issue. As far as I can tell we might be moving towards something that looks like this, correct me if I'm wrong.
{
"profiles": [{
"name": "twitter",
"username": "neutralthoughts"
}, {
"name": "facebook",
"url": "https://www.facebook.com/1231453342"
}
]
}Where username and url have to be declared as one or the other but not both.
Let's also add an example of the "both" scenario, so it becomes something like this:
{
"profiles": [
{
"name": "twitter",
"username": "neutralthoughts"
},
{
"name": "facebook",
"url": "https://www.facebook.com/1231453342"
},
{
"name": "soundcloud",
"url": "https://soundcloud.com/dandymusicnl",
"username": "dandymusicnl"
},
]
}Is there a reason for the both scenario? Otherwise the validator should just make sure one or the other exist and throw errors otherwise "You can't specify a username and url"
It's sort of annoying that themes might sometimes get different values for twitter. Sometimes they can show the username, otherwise they will have to infer the username or just show a "Twitter" link
I was under the assumption we would allow either or both. I don't see a reason why we shouldn't allow someone to put in both their username and url for a social network, and my example is just for illustrating that option :)
Yeah I guess it doesn't affect implementations so much.
It's usually just redundant information, anyway.
And I agree with @opensourcegrrrl that you can just fall back to the "old-school" approach and change one line in your resume when you have changed your Twitter handle etc.
I don't think we should have technical, numerical IDs in the resume which are platform-dependent, internal properties of the specific site that are out of our control.
Adding URLs in addition (which usually just consist of name and username which we have included already) doesn't make this better, and it doesn't give @jayzalowitz the IDs he wished for. So shouldn't we better avoid this disimprovement?
Not every social network provides clear usernames, that why we opted to include an url. I think the discussion is mostly about allowing both for a social network entry, of only allowing one of two.
A reason for allowing both: a templating tool that generates a webpage, could show the username, and make that link to the url, without having to construct that url themselves.
Oh, trust me, the url users will submit will not normalize to the username
without a bunch of edge case catching (I have dealt with millions of social
profiles and tried to get them down to something usable in the machine
context, Ids are important, and I am still willing to fight about that), but
let me be clear.
I will never implement this standard unless both username and link are
available, even optionally, this is a critical feature.
On Sat, Jul 12, 2014 at 9:25 AM, Daan Debie notifications@github.com
wrote:
Not every social network provides clear usernames, that why we opted to
include an url. I think the discussion is mostly about allowing both for a
social network entry, of only allowing one of two.
A reason for allowing both: a templating tool that generates a webpage,
could show the username, and make that link to the url, without having to
construct that url themselves.—
Reply to this email directly or view it on GitHub
#6 (comment)
.
I will never implement this standard unless both username and link are
available, even optionally, this is a critical feature.
Please Jay, could you keep the discussions civil? This kind of muscle flexing is not helping at all.
That said, as I mentioned earlier, my proposal would be to include them both (optionally) for each social network entry. Require at least one of two, and optionally allow two. So we agree on that.
I'm still not convinced of the technical id requirement, and it seems that that is agreed upon by most contributers, so we'll leave that out, at least for now.
Agreed @dandydev.
@mwaclawek I would say it is very important to have a URL option OR a numeric ID option. The reason is that many people on LinkedIn, Facebook and other social networks don't have usernames. If a LinkedIn user hasn't picked a username yet, then the URL is the only way to uniquely identify him/her (in a publicly crawl-able way). If a Facebook user hasn't picked a username yet, then the userId and the URL are the only other ways to uniquely identify him/her (they map to each other, where the URL is just https://www.facebook.com/<userid>, which redirects to https://www.facebook.com/<username> if the username is set).
If you don't have a URL option, say good bye to supporting LinkedIn, Facebook and other social networks that don't have required usernames.
And as said, even for social networks that do have clear usernames, such as Twitter, it can be useful/convenient for the user to add the url to his/her profile as well, just to make life easier for template designers.
Ah, well in the case of twitter, every user has a URL with the same structure taken from the username, so I wouldn't say prepending "https://twitter.com/" is really a problem for template designers.
In addition, if it's optional to have a URL, then the template designer would have to support the case for which only a username is provided anyway, so no work is saved.
Also true.
In any case, I think we all agree on url and username both being valid for a social network entry, and I think we also agree on one of two being required.
Can we also agree on both together being valid as well?
I think both being included should absolutely be allowed. I wouldn't recommend people populate both fields but I see no benefit in marking the inclusion of both as invalid.
SoundCloud is an interesting example because the username does not necessarily map to the URL :O.
This means that if you want the user's URL, you need to have the URL included and cannot use the username. It's not even like LinkedIn, where you may have the username OR the URL. Here only the URL is valid because using the username can produce the incorrect URL.
I'm a little lost, why is url not sufficient to cater for user id's?
Understandably database indexing wouldn't be as great, but they can infer id's and do their own hacks to make it searchable.
I believe we were mostly discussing the merits of including a URL option. We simply touched on the idea of user id's.
{
"profiles": [
{
"name": "twitter",
"username": "neutralthoughts"
},
{
"name": "facebook",
"url": "https://www.facebook.com/1231453342"
},
{
"name": "soundcloud",
"url": "https://soundcloud.com/dandymusicnl",
"username": "dandymusicnl"
},
]
}Good work guys, let's lock down as above. Label applied for PR Needed
Wait, I don't want to throw a wrench in things, but is "name" the right field label? Would "type" be more appropriate? Only reason I say this is I could imagine people getting confused by "name" and thinking it means the name of person's profile that is being referenced.
I know you wouldn't do this, but it could follow logically that either of these could be possible, when iterating through profiles:
{ "name": "twitter", "username": "neutralthoughts" }
Vocalized: "This profile's username is 'neutralthoughts'. It's name is 'twitter'."
{ "type": "twitter", "username": "neutralthoughts", "name": "Thomas Davis" }
Vocalized: "This profile's username is 'neutralthoughts'. It is of type 'twitter' and the name is 'Thomas Davis'.'"
Just a thought.
Agreed, how about network?
On Wed, Jul 16, 2014 at 8:19 PM, Ryan Shea notifications@github.com wrote:
Wait, I don't want to throw a wrench in things, but is "name" the right
field label? Would "type" be more appropriate? Only reason I say this is I
could imagine people getting confused by "name" and thinking it means the
name of person's profile that is being referenced.I know you wouldn't do this, but it could follow logically that either of
these could be possible, when iterating through profiles:{ "name": "twitter", "username": "neutralthoughts" }
Vocalized: "This profile's username is 'neutralthoughts'. It's name is
'twitter'."{ "type": "twitter", "username": "neutralthoughts", "name": "Thomas Davis"
}Vocalized: "This profile's username is 'neutralthoughts'. It is of type
'twitter' and the name is 'Thomas Davis'.'"Just a thought.
—
Reply to this email directly or view it on GitHub
#6 (comment)
.
Thomas Davis
http://thomasdav.is
VP of Tech - Earbits - http://earbits.com
Co-founder - Cdnjs - http://cdnjs.com
Founder - Backbone Tutorials - http://backbonetutorials.com
+1 for network
I realise that might not be entirely accurate for stuff like Skype, but I still think we should roll with it.
I like network, maybe service as an alternative? Both are better than name in my opinion. Good remark, @rxl!
Alright, lock in network for the PR
A bit late, and for the record, +1 for 'network', as in social network.
On Jul 16, 2014 12:20 PM, "Thomas Davis" notifications@github.com wrote:
Agreed, how about
network?On Wed, Jul 16, 2014 at 8:19 PM, Ryan Shea notifications@github.com
wrote:Wait, I don't want to throw a wrench in things, but is "name" the right
field label? Would "type" be more appropriate? Only reason I say this is
I
could imagine people getting confused by "name" and thinking it means
the
name of person's profile that is being referenced.I know you wouldn't do this, but it could follow logically that either
of
these could be possible, when iterating through profiles:{ "name": "twitter", "username": "neutralthoughts" }
Vocalized: "This profile's username is 'neutralthoughts'. It's name is
'twitter'."{ "type": "twitter", "username": "neutralthoughts", "name": "Thomas
Davis"
}Vocalized: "This profile's username is 'neutralthoughts'. It is of type
'twitter' and the name is 'Thomas Davis'.'"Just a thought.
—
Reply to this email directly or view it on GitHub
<
https://github.com/jsonresume/resume-schema/issues/6#issuecomment-49146508>.
Thomas Davis
http://thomasdav.isVP of Tech - Earbits - http://earbits.com
Co-founder - Cdnjs - http://cdnjs.com
Founder - Backbone Tutorials - http://backbonetutorials.com—
Reply to this email directly or view it on GitHub
#6 (comment)
.
Gj everybody