RFC Author profile pages

[MSusik]

Problem

With the incoming release of Invenio.pu,the authors module should be flexible, extensible, etc. (and it should finally work :smile:). This raises a question, how to allow overlays to use it, so that the work done by the overlay's developers won't take much time.

Proposal

The authors module should by default have an implemented layout. This vanilla version will be using author base records, which currently contains the name of the author, the unique identifier and the list of the publications (to be replaced with relations). From those fields, we can compute a lot of information needed for the profiles.

Here is one of the suggested designs for the Inspire overlay. Note that the screenshot is only supposed to show the content of the boxes for the needs of this RFC.

From the fields that I mentioned, we can compute:

• Statistics
• Keywords (if the information is included on the papers)
• Co-authors
• Publication list

I think we might want to organize the default page in similiar way, i.e. by multiple boxes organized in two columns like on the screen.

Now, let's consider every box separately.

Personal details

This box contains information which is specific to the Inspire overlay, so it should be dropped in the default templates.

OR

There should a config variable which will define which subfields of an author record to use for rendering this box. In case no values are provided, the box will not be shown.

Publication list

The default page should not have tabs on top of it. Every paper will appear in the same table. On top of the table there will be a filter box provided by the library that I am using (datatables). The default page should not have claiming functionalities, but it should be easy to include them (for example by switching a config variable).

Note that the tick on the left side of the table is one of the claiming functionalities.

Toggles

The box on the top right is another filtering tool. However, it applies to the whole page. The data computed in other boxes is derived from the list of publications received from the server. Toggling any of the switches filters this list, so that the statistics, graph, all the numbers on the page and the list of the publication might be altered.

It should be easy to implement new toggle. There should be a config variable that will decide which toggles should be used. By default all of them should be turned on (?).

The box should by default contain a title Display toggles

Statistics

All the information is easily accessible using author base records, so no changes in the box are needed. Only the name h HEP index will be changed to h index.

Keywords

All the information is easily accessible using author base records, so no changes in the box are needed. The only question is whether I can assume if the service stores the information about papers' keywords or not.

Co-authors

All the information is easily accessible using author base records, so no changes in the box are needed.

What's next

I would like to hear from you what are the requirements for the author pages for the services other than Inspire. Moreover, I am far from sure about what should be displayed on this page and I need your input. Also, please discuss whether the idea of having a default page implementation directly inside Invenio package is the right one.

@glouppe @jmartinm @kaplun @jirikuncar @tiborsimko

[kaplun]

I think also TIND was very interested into this work, cc: @PXke

[glouppe]

Also, please discuss whether the idea of having a default page implementation directly inside Invenio package is the right one.

This. To me, what we put in author pages and how we display it is very overlay-specific. Accordingly, I would put focus on the backend in Invenio, so that the job that is done in the overlay merely amounts to write the template. By default, I would therefore go for a minimalist template in Invenio, e.g. as we have for records. I really dont think we need to put effort in doing something fancy though (e.g., no toggles or magic js effects). This should be left to the overlay developers own preferences.

[lnielsen]

@MSusik Nice job on the layout and presentation. Looks very clean

I agree with @glouppe that presentation and underlying structure is highly dependent on the overlay so clean separation between all parts is critical. E.g. Inspire has all of HEP literature, thus you can do citation analysis. On Zenodo, I only have what the author submits, thus author profile would be different. So yes, some very simple default profile would be nice

Other issues to think about:

• User profile / author profile integration: In Zenodo I would likely only have author profiles for an existing user, thus nice integration between the Invenio user and the author record would be great. Ideally, the user shouldn't see a difference between the two.
• Integration with external author services such as ORCID and ImpactStory.
• Relation with oauthclient for ORCID sign-in/out.

[jalavik]

There should a config variable which will define which subfields of an author record to use for rendering this box

Just a minor comment: I'd say it could be cleaner to try to keep these kinds of customizations as part of template overriding etc. rather than Python config variables when possible.

@MSusik Nice job indeed!

[MSusik]

As there are few people here who are appreciating the design, I need to note here that it is also a work of @espacial and @jmartinm.

[tiborsimko]

User profile / author profile integration

:+1: Another example includes other personal features, such as alerts or baskets, that many sites use heavily. This is not to say that the author pages should present that information on the same page; but that it would be good if the keep the overall design of "person-related pages" somewhat homogeneous, so that one could later plug various facilities, such as alerts and baskets. Kind of keeping close visual link with the user dashboard for all things people related.

To me, what we put in author pages and how we display it is very overlay-specific

:+1: for thin Invenio and thick overlays. We can come with a good example for the demo site, and people would be able to look and see and get inspiration from what INSPIRE does, what Zenodo does, etc.

[tiborsimko]

Two more quick comments that may not have been highlighted previously.

1. Author pages for already-disambiguated authors. See e.g. the collection of "People" in Invenio v1.2.0 that is done via MARC21 authority records. Here, the display is of "bibliographic nature", but it has close relation to author pages. This is the old theme: if an installation has already disambiguated people, say because of taking advantage of local institute phone book, they do not need to run author disambiguation in order to display nice author page.

2. Non-author summary pages. Looking at current author pages, they basically provide a publication summary, citation summary, keyword summary, etc for a set of records, defined by "what are my publications?". One could imagine creating other useful "summary pages" of the same type, answering queries such as "what is the summary page for this institute", or "for his subject category", or for any general Invenio query such as "for the topic of neutrino oscillations"? We could think of the same infrastructure, where author pages would be an instance of these generic "summary pages" facility, with additional author-related boxes. (e.g. see Institutes collection in v1.2.0, e.g. see generic "citation summary pages)

[MSusik]

for thin Invenio and thick overlays. We can come with a good example for the demo site

OK, so the question is what should be the thin version? If we are going to scrape all the fancy functionalities, we will be left with only the list of the publications, which will be accessible from the search engine as well. As the profile page is actually a wrapper over statistics with some interactivity included (like claiming), it might not be the best idea to implement such a solution.

1. Author pages for already-disambiguated authors.

As in the future the authors module will be heavily dependant on relations, we might think of writing a tool to link such already disambiguated authors. Then, we will be able to present them in the same way as here.

1. Non-author summary pages.

I agree, those are similiar features and we need to consider generalization. It might be not a good idea for Inspire, though, where author pages offer far more features than the rest of mentioned pages.

Thanks!

[tiborsimko]

As in the future the authors module will be heavily dependant on relations, we might think of writing a tool to link such already disambiguated authors.

In the case of MARC21 authority records, this will be relatively easy. The link is already denoted in the metadata by 100 $0, so that when the new uploader parses such an input, it can create corresponding entries in the relations table.

In the case of old exact-name-based author pages, we may simply fall back to the generic-search-query use case, using non-author-summary-page facility.

[MSusik]

As we are not going to provide a default look for Invenio, I close this RFC.