WIP: #296 filter for PhD and post docs alongside advisors

[SaniHarouna-Mayer]

copy of recent PR to the right branch now..

[sbillinge]

thanks @SaniHarouna-Mayer . Please can you move over the comments from the other PR?

[sbillinge]

I think a description could help here.

Also, we will need an examplar (above). Add it to an existing education scopatz item.

[SaniHarouna-Mayer]

Previous comments:

---

Thanks @SaniHarouna-Mayer this looks very good, well done!

How will it be used? we will need the code that calls it. Also, it will need a test.

Finally, a thought is thatthink that we probably want to get phd and postdoc advisors only for a single person so we won't need to iterate over an input_contacts, though this is just a guess as I am not sure how you plan to deploy this....

We ill also need to dereference the advisor name, so if the advisor is sbillinge we will use fuzzy_retrieval to get this person either from the people or contacts collection. You may still be working on that. A helpful comment in the PR would help me know where you are with the PR.

Thanks so much! Again, a fine piece of code, very clean!

---

Thank you!! I will need help with the test and the usage within the code.
I will catch up on this with Songsheng tomorrow and work on your other
comments then.

---

sounds good.

Basically in the main code it is just getting all the collaborators etc.
for a single person that is specified on the command line....e.g., in
general that person will be sbillinge... so if the people collection is
loaded into the variable ppl, let's say, the code will look something
like

phd_advisors = [position["advisor"] for position in ppl["education"] if
ppl["_id"] is person]

then we would generally load phd_advisors into some dictionary that is
passed to the template and then the template will have to be modified to
unpack that and insert it into the built document.

one more thing, the elements of the list phd_advisors (list in case
someone does two PhD's!) could be actual name of a person, or an _id of
a person or whatever, so we would run them through fuzzy_retrieval to
get the full person and then load their canonical name into whatever is
passed to the template.

S

---

@SaniHarouna-Mayer btw this PR should be in to the recent-collaborators branch

[SaniHarouna-Mayer]

@sbillinge
I am struggling to understand the architecture of the whole code and how I am supposed to implement my contribution:

1. Where is function supposed to be called?

then we would generally load phd_advisors into some dictionary that is
passed to the template and then the template will have to be modified to
unpack that and insert it into the built document.

2. Where and how will the output be passed to the template and
3. how will it be inserted into the built document? (latex method in RecentCollabsBuilder class in recentcollabsbuilder.py?)

We ill also need to dereference the advisor name, so if the advisor is sbillinge we will use fuzzy_retrieval to get this person either from the people or contacts collection. You may still be working on that.

4. To dereference the advisor name, simply add a key to the dictionary, which tells from which db the information is retrieved from?

Thank you!

[SaniHarouna-Mayer]

Hi @sbillinge, could you please doublecheck if I got the guideline the right way?

• The filter function from tools.py is called to coabuilder.py and filters for an advisor name and the positions in people.yml and contacts.yml
• I extend the excel method in coabuilder.py to build an xsls file which contains the information required how it is shown in the coa_template

Right now there are no advisor entries at all in people and contacts. How should we proceed to get this updated in the end? More specifically, where can I find those information, since it won't be easily found googling like we did when updating the institutions and contacts?

Thank you!

[sbillinge]

Thanks for reaching out Sani. It looks as if you are doing Issue regro#296 which is to find PhD and post-doc advisors.

If it was me, my plan might look like this:

1. We cannot currently search for advisors because it is not recorded so there will have to be a schema update. First thing then is to decide where the advisor info should go.
2. Once it is decided where to go, make something that will allow us to test our code. Since we always run it for sbillinge in general we just need to put the advisor info into the sbillinge entry for now, so modify people accordingly.
3. the program needs to take that information and insert in in the correct place in the template. One thing to figure out is whether it will need to add new rows to the template (as the authors one does) or not, but in any case, write the code for putting the info the spreadsheet, taking inspiration from the code already there.
4. Now we have testing going on (thanks to Hung) we will have to modify the regolith schem with these new fields. Return to this when we have everything working and building properly.

[sbillinge]

Now, to move this forward more quickly I can put some discussion and thoughts I have already had. Let's work on (1) first, where to put the info. The obvious place is to put it into the education and employment fields of the people collection. I would then think to have an optional advisor field in the education schema and then add the advisor when the education involved research, e.g., phd. For the post-doc positions, they will appear in employment not education. It doesn't make sense to me to have an advisor field in education because most education is things like bank manager or hairdresser or whatever, so I would think that we would need a more generic word, maybe mentor. I guess hairdressers and bank managers can have mentors, but for post-docs the mentor could be the advisor. Not 100% sure about that but that would be my first suggestion.

[sbillinge]

Let's work on (2) . The way the program is run is regolith build recent-collabs --people sbillinge so the person is specified that we want to search to find the advisors. It seems that we would then have to iterate through the education and employment lists only of the one person who was specified on the command line and find (a) all the phd degrees in education and extract the advisor and (b) all the entries in the employment that are postdocs and extract the mentors. I guess another way to do it is to have an optional advisor field in employment that will, presumably, only be used in the case of a postdoc, and then the job here is to just find all the employments that contain an advisor, then get that value. This might actually be better than my previous idea of mentor!

[sbillinge]

for (3) it is a matter of copy-pasting code that is already there and adapting it.

[sbillinge]

btw, my PhD advisors were Takeshi Egami and Peter Davies and my postdoc advisor was George Kwei.

[SaniHarouna-Mayer]

Thanks Simon, this is really helpful!

[SaniHarouna-Mayer]

(1):

Now, to move this forward more quickly I can put some discussion and thoughts I have already had. Let's work on (1) first, where to put the info. The obvious place is to put it into the education and employment fields of the people collection. I would then think to have an optional advisor field in the education schema and then add the advisor when the education involved research, e.g., phd. For the post-doc positions, they will appear in employment not education. It doesn't make sense to me to have an advisor field in education because most education is things like bank manager or hairdresser or whatever, so I would think that we would need a more generic word, maybe mentor. I guess hairdressers and bank managers can have mentors, but for post-docs the mentor could be the advisor. Not 100% sure about that but that would be my first suggestion.

I already implemented these changes quite similar to your ideas. I don't quite see the confusion with the advisor name. I changed it to mentor in education and employment. I'd like to stick with the same name in education and description since it describes the same relationship and the code would loose lucidity otherwise.