Author name URLs

[mjpost]

I can't find where I commented on this, but now that ACL 2020 is collecting links to ORCid, Semantic Scholar, and Anthology pages, I'm reminded that we don't have stable author page names. For example, if another Matt Post comes along, we have to fork the current pages.

I like Semantic Scholar's approach, where for example my page is:

https://www.semanticscholar.org/author/Matt-Post/38842528

I don't know how the integer is selected, but we could use a similar system, say starting at 1, and moving up from there. When there is no ambiguity, the base page would redirect to /1, e.g.,

https://www.aclweb.org/anthology/people/matt-post → https://www.aclweb.org/anthology/people/matt-post/1

When there is ambiguity, the base page would then be used to hold variants with no assigned ID.

[davidweichiang]

Since ACL 2020 intends to share information with future conferences, it may be desirable to commit to making all current author pages stable (so you will always be matt-post and future Matt Posts will have to get a suffix).

To handle ambiguous names, it may help to distinguish between names and people.

So, if there's only one Matt Post, then https://www.aclweb.org/anthology/names/matt-post redirects to https://www.aclweb.org/anthology/people/matt-post. But if a new Matt Post arrives on the scene; somehow he is assigned a new id, say, matt-post-nd. Then https://www.aclweb.org/anthology/names/matt-post becomes a disambiguation page that contains:

• Links to https://www.aclweb.org/anthology/people/matt-post and https://www.aclweb.org/anthology/people/matt-post-nd.
• Any papers written by "Matt Post" which cannot be positively assigned to either person.

[davidweichiang]

I also wonder if, rather than creating a new system of IDs on top of ORCID, START, DBLP, Semantic Scholar, and Google Scholar, should we adopt one of those existing systems of IDs?

[nschneid]

In principle I like the idea of adopting ORCID since uniquely identifying people is its entire purpose. START usernames are not as clean (I've seen people with multiple START IDs), and the others are automatically mined and therefore subject to error. But what about authors who don't have an ORCID? I suspect in any event we'll need a mixture of external and internal IDs.

[akoehn]

This is not an easy problem: We should definitely not roll our own ID schema, relying on semanticscholar seems to brittle (how long will they / their IDs be around?); ORCID seems to be the best option because it is the only ID explicitly made for this job and I am very much in favor of future conferences collecting ORCIDs for submissions. However, it is not easy to 1) find the orcids for already existing papers and 2) deal with people without orcid.

The proposal by @davidweichiang seems sensible to me (existing author keeps URL on clashes), the /names/ URL would then be linked to from /people/ pages of people with multiple authors, similar to disambiguation sites on Wikipedia?

And whoever has access to people organizing conferences: please lobby for orcid, it will make our lives easier in the long run :-)

[knmnyn]

Hi all: I'd also support ORCID. I had brought this up to TACL and CL before and then I understood that MIT Press was pursuing this anyways, so the editors on both CL and TACL stopped worrying about it. I agree with Arne, not to create our own. This is exactly why ORCID was created in the same guise as DOIs, and it will survive any one potential parties' demise (the verdict is not so clear with Semantic Scholar, IMHO). I also agree with Nathan in that we definitely need at least an internal system. I think we should use ORCID as a primary vehicle (and redirect folks to those IDs where possible) but also retain our own author URLs for cases where there are multiple namesakes; (matt-post, matt-post-2) . When and if an author mints a ORCID and reveals it to us, we permanently forward the existing namesake page to the ORCID (so matt-post gets redirected to 0000-0002-1297-6794 and we don't re-use matt-post again; the next matt-post is matt-post-3 Cheers, Min

…

-- Min-Yen KAN (Dr) :: Associate Professor :: National University of Singapore :: NUS School of Computing, AS6 05-12, 13 Computing Drive Singapore 117417 :: +65 6516 1885(DID) :: +65 6779 4580 (Fax) :: kanmy@comp.nus.edu.sg (E) :: www.comp.nus.edu.sg/~kanmy (W)

On Fri, Nov 8, 2019 at 7:16 PM Arne Köhn ***@***.***> wrote: This is not an easy problem: We should definitely not roll our own ID schema, relying on semanticscholar seems to brittle (how long will they / their IDs be around?); ORCID seems to be the best option because it is the only ID explicitly made for this job and I am very much in favor of future conferences collecting ORCIDs for submissions. However, it is not easy to 1) find the orcids for already existing papers and 2) deal with people without orcid. The proposal by @davidweichiang <https://github.com/davidweichiang> seems sensible to me (existing author keeps URL on clashes), the /names/ URL would then be linked to from /people/ pages of people with multiple authors, similar to disambiguation sites on Wikipedia? And whoever has access to people organizing conferences: please lobby for orcid, it will make our lives easier in the long run :-) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#623?email_source=notifications&email_token=AABU7263KCNSXUMI2OJ3NM3QSVDBLA5CNFSM4JJL7222YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDQNTTQ#issuecomment-551606734>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU72ZKWT2CZMAR4ULXX3LQSVDBLANCNFSM4JJL722Q> .

[mjpost]

It seems ORCID is the way to go, when we have it. It's too bad that the ACL email that went out recently collected pretty much everything except ORCIDs.

[knmnyn]

It’s not too late per se. I think we could encourage Rich Gerber at START to add a field to the global profile to collect ORCID. It’d just not be mandatory at this point. - M

On Wed, 27 Nov 2019 at 08:33, Matt Post ***@***.***> wrote: It seems ORCID is the way to go, when we have it. It's too bad that the ACL email that went out recently collected pretty much everything *except* ORCIDs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#623?email_source=notifications&email_token=AABU723RXZIW4BMDNAM5Q53QVW55FA5CNFSM4JJL7222YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFH4KQI#issuecomment-558875969>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU7225IDFY3VAM3ETPEZTQVW55FANCNFSM4JJL722Q> .

-- - M

[mjpost]

It would be good to have that in START, but without it being mandatory, I don't think anyone will fill it out. Though I bet we can triangulate them with all the other information we're getting.

[knmnyn]

Very true. If there's an automatic triangulation software one of us writes, we could have it validate the result by sending an email to the START user. Cheers, Min

…

-- Min-Yen KAN (Dr) :: Associate Professor :: National University of Singapore :: NUS School of Computing, AS6 05-12, 13 Computing Drive Singapore 117417 :: +65 6516 1885(DID) :: +65 6779 4580 (Fax) :: kanmy@comp.nus.edu.sg (E) :: www.comp.nus.edu.sg/~kanmy (W)

On Wed, Nov 27, 2019 at 11:17 AM Matt Post ***@***.***> wrote: It would be good to have that in START, but without it being mandatory, I don't think anyone will fill it out. Though I bet we can triangulate them with all the other information we're getting. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#623?email_source=notifications&email_token=AABU722Z3CZ6FGSGFOQG6ALQVXRETA5CNFSM4JJL7222YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFIEUPA#issuecomment-558910012>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU726HV6TLWHV4VIBSKF3QVXRETANCNFSM4JJL722Q> .

[mjpost]

A good idea. Though I suspect that many people haven't even registered for an ORCID. I'm fairly trendy with these things and only recently did so myself.

[mbollmann]

Semantic Scholar is the main source of information in the ACL form, and that one asks for ORCID on sign-up, so that could be a place to start.

[akoehn]

@mbollmann I don't understand your suggestion (in: I do not even know whether you made a suggestion).

In my opinion, we (that is probably @mjpost) should lobby for adding (ideally: required) ORCID fields into future submission processes. Without that step, there will always be additional manual work to perform matching and I don't think that is sustainable in the long run. When ORCIDs are not introduced by conferences, there is little point in introducing them here.

The point of ORCIDs is that they are clean; performing error-prone matching all the time on our end defeats its purpose.