This is the simplest search that triggers returning every result in a single page:
inspirehep.net/search?ln=en&ln=en&p=&of=hb&action_search=Search&sf=earliestdate&so=d&rm=citation&rg=25&sc=0

Please try not to abuse this issue.

Just in case we decide not to use Invenio trac instance, we might like to consider:

• RT
• This issue tracker here
• our own trac

In some records, e.g http://inspirehep.net/search?ln=el&ln=el&p=Monthus%3A2015rua&of=tlcv&action_search=%CE%91%CE%BD%CE%B1%CE%B6%CE%AE%CF%84%CE%B7%CF%83%CE%B7&sf=earliestdate&so=d&rm=&rg=25&sc=0
in the date is printed %(N/A). I think the problem is caused because in that part of the code
date = year + date[2:4] + '00' , we set the day to 0. Any ideas?

After submitting a conference record from the record editor, a new CNUM is generated if there is none in the record. This works fine in general, but is broken when the date in 111__x is incomplete and does not contain a starting day, but only the year and month.
In that case, instead of putting zeros as the day part of the CNUM, which is the convention in use, it leaves the day off, resulting in a CNUM of the form C\d{2}-\d{2}\.\d.

The affected records fail the migration to labs, as documented in #304.

pull the newly merged invenio and creat a new dep branch on tislnx1 and install it

The records returned by this query: https://inspirehep.net/search?ln=en&cc=Conferences&ln=en&cc=Conferences&p=411__n%3A%2F%5B%5E0-9%5D%2F&action_search=Search&sf=conferencestartdate&so=d&rm=&rg=25&sc=0&of=hb have non-numerical values in the 411__n field. Those values should be cleaned, to avoid over-complicating the corresponding DoJSON rules.

This is probably better handled by automated curation (@kaplun).

We need a way to compute citations on legacy and export them into labs.

For this reason we need in labs to have corresponding models for:

-- a table for logging changes in the citation dict
CREATE TABLE IF NOT EXISTS rnkCITATIONLOG (
  id int(11) unsigned NOT NULL auto_increment,
  citee int(10) unsigned NOT NULL,
  citer int(10) unsigned NOT NULL,
  `type` ENUM('added', 'removed'),
  action_date datetime NOT NULL,
  PRIMARY KEY (id),
  KEY citee (citee),
  KEY citer (citer)
) ENGINE=MyISAM;

CREATE TABLE IF NOT EXISTS rnkCITATIONDICT (
  citee int(10) unsigned NOT NULL,
  citer int(10) unsigned NOT NULL,
  last_updated datetime NOT NULL,
  PRIMARY KEY id (citee, citer),
  KEY reverse (citer, citee)
) ENGINE=MyISAM;

A simpler handler could be built on prod to export the citation log.

E.g.

file citation.py:

from json import dumps

from invenio.dbquery import run_sql

def index(req, action_date="1970-01-01 00:00:00"):
    req.set_header("content-type", "application/json")
    res = run_sql("SELECT id, citee, citer, type, action_date 
                   FROM rnkCITATIONLOG WHERE action_date>=%s 
                   ORDER BY action_date ASC LIMIT 100000", (action_date, ))
    comma = ""
    req.write("{")
    for row in res:
        req.write("%s%s" % (comma, dumps(row))
        req.flush()
        comma = ","
    req.write("}")

Then a simple query to:

http://inspirehep.net/citations.py?action_date=2015-01-01

would do the trick :-)

• inspirehep/refextract#15
• inspirehep/refextract#18

Just a reminder 😃

This is the current state of the 372__a field in INSPIRE Experiments:

   1 5.4
   1 7
   1 7.1
   1 8
   1 ATOM
   1 Dark energy
   1 Gamma rays
   1 Grand Raiden
   1 HERA experiments
   1 Heavy Ion Physics at Low Energies
   1 ISIS experiments
   1 In-Flight Radioactive Beam Production
   1 Micro-Beam Diagnostics
   1 NSLS
   1 Neutrons
   1 Nuclear Astrophysics
   1 Optical
   1 PMO
   1 Particle Astrophysics/Cosmology
   1 Photoreactions
   1 Physics with Laser
   1 R&D
   1 SNOLAB
   1 SPSC experiments
   1 SPring-8
   1 Strage Quarks
   1 Theoretical
   1 VEPP-4M experiments
   2 3.3.1
   2 6.4
   2 8.3
   2 9
   2 Bevalac
   2 CESR experiments
   2 DAFNE experiments
   2 DORIS experiments
   2 Extrasolar planets
   2 Neutrinos
   2 Solar system
   2 Ultraviolet
   2 VEPP-2M experiments
   3 1.1.2
   3 1.3
   3 5.2
   3 Accelerator Test
   3 ELSA
   3 Heavy Ion Physics at Intermediate Energies
   3 Infrared
   3 LEP experiments
   3 Laser-Electron Photon Facility
   3 Particle physics experiments
   3 Series E experiments
   3 TRISTAN experiments
   4 4.3
   4 6.2
   4 Ring Cyclotron experiments
   5 2.6
   5 4.2
   5 7.2
   5 AD experiments
   5 Balloon Experiments
   5 Nonlinear beam dynamics experiments
   6 3.5
   6 MAMI
   6 RMC experiments
   7 1.5
   7 8.2
   7 8.4
   7 Gravity
   7 RHIC experiments
   7 Radio
   8 5.1
   8 6.1
   8 ISOLDE
   9 2.1
   9 3.2.1
   9 3.2.2
   9 CMB
  10 8.1
  10 Accelerator RD
  10 Particle Physics
  10 X-ray
  11 5.3
  11 7.3
  11 Cyclotron Laboratory
  11 LEAR experiments
  12 3.1.1
  12 3.3.2
  12 Dark matter
  13 3.1.2
  13 3.4
  13 9.1
  13 ATLAS
  14 1.1.1
  14 6.3
  15 2.4
  15 3.3.3
  15 Neutrino
  16 2.2
  16 4.1
  18 Gamma-ray
  18 LHC experiments
  18 Strange Quarks
  19 Few Body Nuclear Properties
  20 EMU experiments
  20 Properties of Nuclei
  21 1.2
  21 Nucleon and Meson Form Factors and Sum Rules
  21 PS experiments
  22 1.4
  22 Astronomy
  24 Cosmic ray
  27 2.3
  35 N* and Meson Properties
  36 SPS experiments
  37 2.5
 201 AGS experiments
 269 2

If I'm not mistaken only the numerical values are expected (see: https://inspirehep.net/info/Experiments/list), all the others are input errors. But I believe there's still useful data to be recovered in those: can I have your help in building a mapping from these values to the actual numbers?

Here is the current status of 035__9 in HEPNames:

   1 A.H.Sanjari.1
   1 BAi
   1 BIA
   1 L.Santoni.1
   1 ORCKD
   1 R.Mohayaee.1
   1 ResearchID
   1 SPIRES
   1 Scopus
   1 TWITTER
   1 WikiPedia
   2 ORCI
   2 RESEARCHERID
   3 ORICD
   4 ResearcherID
   4 SCOPUS
   5 ORCiD
  24 VIAF
  65 GoogleScholar
 139
 215 JACOW
 223 Wikipedia
 275 ARXIV
 779 DESY
 903 SLAC
1677 KAKEN
1915 arXiv
8991 CERN
8998 ORCID
53694 INSPIRE
58685 BAI

After correcting the obvious mistakes we get the following ID schemes:

    1 SPIRES
    1 TWITTER
    5 SCOPUS
    7 RESEARCHERID
   24 VIAF
   65 GOOGLESCHOLAR
  215 JACOW
  224 WIKIPEDIA
  779 DESY
  903 SLAC
 1677 KAKEN
 2190 ARXIV
 8991 CERN
 9009 ORCID
53694 INSPIRE
58687 BAI

Which ones do we want to preserve? Could you help me add their expected format to the schema? I'm currently missing SLAC, GOOGLESCHOLAR, VIAF, RESEARCHERID, SCOPUS, TWITTER, SPIRES of the above list.

The record creation date, according to the documentation, is found in 961__x: https://twiki.cern.ch/twiki/bin/view/Inspire/DevelopmentRecordMarkup

The XME format is instead putting it in 961__c. Compare https://inspirehep.net/record/4328/export/xm and https://inspirehep.net/record/4328/export/xme.

[...]
We often need to format lists of authors in the correct MARC format when we catalogue a new publication or to add some missing authors in Bibedit-Text-MARC. It would be nice to have a small tool that we could use easily on our PCs. Here are some examples that you could use for testing, in principle we have two different models:

• One without affiliations

K. Berkelman, D. Cords, R. Felst, E. Gadermann, G. Grindhammer, H. Hultschig, P. Joos, W. Koch, U. Kötz, H. Krehbiel, D. Kreinick, J. Ludwig, K.-H. Mess, K.C. Moffeit, A. Petersen, G. Poelz, J. Ringel, K. Sauerberg, P. Schmüser, G. Vogel, B.H. Wiik, G. Wolf

The result should be in that format:

100__ $$aBerkelman, K.
700__ $$aCords, D.
700__ $$aFelst, R.
700__ $$aGadermann, E.
700__ $$aGrindhammer, G.
700__ $$aHultschig, H.
700__ $$aJoos, P.
700__ $$aKoch, W.
700__ $$aKötz, U.
700__ $$aKrehbiel, H.
700__ $$aKreinick, D.
700__ $$aLudwig, J.
700__ $$aMess, K.-H.
700__ $$aMoffeit, K.C.
700__ $$aPetersen, A.
700__ $$aPoelz, G.
700__ $$aRingel, J.
700__ $$aSauerberg, K.
700__ $$aSchmüser, P.
700__ $$aVogel, G.
700__ $$aWiik, B.H.
700__ $$aWolf, G.

• One model with affiliations identified with numbers:

F. Durães1, A.V. Giannini2, V.P. Gonçalves3,4 and F.S. Navarra2
1 CERN
2 Fermilab
3 Lund University
4 Instituto de Física, Universidade de São Paulo

The result should be in that format :

100__ $$aDurães, F.$$u1
700__ $$aGiannini, A.V.$$u2
700__ $$aGonçalves, V.P.$$u3$$u4
700__ $$aNavarra, F.S$$u2

Or you can also replace the numbers with the subfield __v affiliation as it is on the list ( 700__ $$aGonçalves, V.P.$$vLund University $$vInstituto de Física, Universidade de São Paulo)
[...]

spires allows the search "find eprint HEP-TH 9304057" whereas Inspire demands a slash. That causes eprint searches via easy search to fail.

Cheeky title, serious question. This is the current state of the 043__a field in INSPIRE Jobs:

   1 Europe / South America
   1 Europe, North America
   1 North Americsa
   1 Noth America
   2 Asia, North America
   2 United States
   5 eu
   7 na
  14 Choose one
  24 AF
  70 Middle East
  88 Africa
 140 Australasia
 162 South America
 213 Australia
 715 Asia
4009 North America
4554 Europe

Let's say that we assume the 7 continent model.

1. Shall continent be an array, so that I can accomodate all the records with a /?
2. What about Middle East? Is it too contentious to just use Asia for it?

@tomaszgy commented on Wed Jun 29 2016

All records from Experiments are missing connection by recid to their affiliation (Institutions). Field 119__u contains sometimes institution's name. Not always though, there are cases where it contains strings not being a name of any institution (e.g. Astro).

Would be great, if we had that fixed so we could connect Experiments and Institutions.

@kaplun

https://rt.inspirehep.net/Ticket/Display.html?id=626193

In case the previous comment was not clear:

Collaboration is stripped from the content of 710__g and added as default by the display formats.
But Group, Consortium, ... stay in the metadata.
I vaguely remember that somewhere sometime there were exceptions that 'Collaboration' is not added to such fields on display. But my memory might be wrong.

Fact is that
http://inspirehep.net/search?ln=en&p=710__g%3A%2FGroup%24%2F&of=hb&action_search=Search
looks stupid.

In this particular case there is an additional problem since "Heavy Flavor Averaging Group (HFAG)" doesn't end in group.
Here we can decide whether we want to change the code or the metadata.
But I can't ask that guy whether he is OK if I rename it to
"Heavy Flavor Averaging Group" if that doesn't work either.
And if someone is touching the code we might take care of 'group' in the middle of the string too.

well it's not so simple. the code

https://github.com/inspirehep/inspire/blob/master/bibformat/format_elements/bfe_INSPIRE_authors.py#L291-L295

assumes e.g.

['Atlas', 'CMS'] => Atlas and CMS Collaborations

['Atlas', 'Heavy Group', 'Foo Team', 'CMS'] => Atlas and Heavy Group and Foo Team and CMS Collaborations

if I skip "collaboration(s)" at the end when there is a Group or Team or somesuch it looks odd

if I add Collaboration to each term not containing Group, Team, etc. then it becomes lengthy

Atlas Collaboration and Heavy Group and Foo Team and CMS Collaboration

and then some extra logic could be applied to different order

Atlas and CMS Collaborations and Heavy Group and Foo Team

in addition to "Collaboration", "Consortium", "Group", "Working Group", "Team", "Task Force" I see things in 710__g like

"Le Groupeur Lineaire de SPIRAL"
"Groupe De L'Aimant De La Division Du Synchrotron À Protons"
"Crew of the Intensity Upgrade Study"
"Indian Association for the Cultivation of Science"
"Sanford Laboratory at Homestake"
"Center for Theoretical Astrophysics, Los Alamos National Lab"
"The Abdus Salam International Centre for Theoretical Physics"

Some arXiv records don't have PDFs associated, e.g. arXiv:1502.06786, but we still display a link to the PDF on the record.

Instead, the display element should check whether we have the arXiv PDF and if not don't display the link.

@tomaszgy commented on Fri Jul 01 2016

It seems like the link between a person from HepNames collection and his/hers supervisor is lost. At least, there is no connection by recid, only by INSPIRE ID e.g. INSPIRE-00188911.

Would be more convenient if we had recids.

Thanks a lot in advance, @kaplun, for fixing it 😄

@kaplun commented on Thu Jul 07 2016

I am implementing it at the moment, and this is the occasion to also do autoclaim for all those HEPNames for which we have an INSPIRE ID. Yay!

For the migration, we want to keep the information of deleted records.

Right now, the XME format only contains minimal information (compare XME and bibedit).
Instead, it should contain the full info of the record.

Currently we have some authors that have multiple 693__e values, see:

https://inspirehep.net/record/1058096/export/xm

<datafield tag="693" ind1=" " ind2=" ">
  <subfield code="e">SLAC-PEP2-BABAR</subfield>
  <subfield code="e">CERN-ALPHA</subfield>
</datafield>
<datafield tag="693" ind1=" " ind2=" ">
  <subfield code="e">CERN-LHC-LHCB</subfield>
  <subfield code="z">Current</subfield>
</datafield>
<datafield tag="693" ind1=" " ind2=" ">
  <subfield code="e">SUPERB</subfield>
</datafield>

Should it be like this? Should we expect this field to have more than one entry? (maybe the author was working on more than one experiment at the same time?)

Thanks!

The newly introduced prodsync bitasklet (see #122) should be amended to:

• use AFS rather than NFS (when redis is not available)
• gzip the output
• fix some tuple being sent to output

Given a DOI prefix we could export the ORCID DOI association.

Here's the current status of 410__9:

   1 Center of Space Science and Application
   1 Crete Center for Theoretical Physics (CCTP)
   1 Institute of Physical and Chemical Research
   1 Lab. Nucl. En. Phys.
   1 Nat. acad.
   1 National Scientific & Educational Center
   1 Sci. Inst.
   1 Tech
   1 Univ. ctr.
   1 Univ., phys., astron., comput., sci.
   1 acad. si.
   1 http://www.univ-tebessa.dz/fr/
   1 ins., sup. tec. tech.
   1 inst., sci.
   1 univ. ctr. res. cer.comp. mater.
   1 univ., cath.
   1 univ., dept., Sci., comp.
   1 univ., tech., wirt.
   1 web
   4 INSPIRE
   4 Univ.
   7 univ.
  21 ADS
4108 DESY_AFF
6640 DESY

I'm not sure what the difference between DESY_AFF and DESY is, but together they comprise the sheer majority of the name_variants sources. Is the source still useful, then? Do we want to preserve it?

(There's also some instances of bad data in this field).

Now that trac-128 is in Invenio/master and old-inspire/master, the corresponding patch needs to go into new-inspire/master.

Just two records in Experiments have a non-numerical value in 510__0: https://inspirehep.net/search?ln=en&cc=Experiments&p=510__0%3A%2F%5B%5E0-9%5D%2F&action_search=Search&sf=experimentname&so=a

Since they are just two I believe this is better handled by manual curation (@annetteholtkamp).

e.g. https://inspirehep.net/author/O.W.Kenobi.1 redirects to https://inspirehep.net/author/search?q=O.W.Kenobi.1 instead of having a 404 status.

I noticed this because a link from wikipedia to INSPIRE was broken, and wikipedia has bots monitoring broken links, which this "feature" prevents.

My beloved wife reports that it's currently technically difficult to remove comments from our LaTeX output formats. E.g.:

https://inspirehep.net/search?ln=it&ln=it&p=storaci&of=tlcv&action_search=Cerca&sf=earliestdate&so=d&rm=&rg=25&sc=0

E.g. one would need to use regular expression in order to automatically strip away % in front of lines such as:

%2 citations counted in INSPIRE as of 24 Aug 2016

or

%(Aug 23, 2016)

Not all editor supports it and not all users master regexp.

One possible quick solution is e.g. to add a constant improbable suffix after the percentage char, so that even dummy editors can search and replace them.

E.g.

• %-- 2 citations counted in INSPIRE as of 24 Aug 2016
• %== (Aug 23, 2016)

See e.g. here https://inspirehep.net/record/1418886/export/hx, the bibtex outputs contains an URL to the INSPIRE copy of the arXiv PDF, which is not even publicly visible from the website.

There are 16K documents that have a DOI but no 773 information(!)
https://inspirehep.net/search?ln=en&p=0247%3ADOI+and+not+773__p%3A**&of=hb&action_search=Search&sf=earliestdate&so=d&wl=0

An easy check can be written that populates 773 from Crossref api:
e.g.
http://api.crossref.org/works/10.1103/PhysRevD.1.1851.3

Special care has to be given to normalize journal title from the start.

The records returned by this query: https://inspirehep.net/search?ln=en&ln=en&p=999C5y%3A%2F%5B%5E0-9%5D%2F&of=hb&action_search=Search&sf=earliestdate&so=d&rm=&rg=25&sc=0 have non-numerical values in the 999C5y field. Those values should be cleaned, to avoid over-complicating the corresponding DoJSON rules.

This is probably better handled by automated curation (@kaplun).

w3c validator complains that the mandatory type attribute is missing in the style element

ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 376)  <style>
ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 377)    @media print {
ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 378)     a[href]:after {
ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 379)     content: none !important;
ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 380)     }
ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 381)    }
ebf14555 (Eamonn Maguire        2015-11-09 15:28:05 +0100 382)  </style>

Always check validator when changing HTML source!

https://validator.w3.org/check?uri=http%3A%2F%2Finspirehep.net%2F&charset=%28detect+automatically%29&doctype=Inline&ss=1&group=0&verbose=1&user-agent=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices

The attribute given above is required for an element that you've used, but you have omitted it. For instance, in most HTML and XHTML document types the "type" attribute is required on the "script" element and the "alt" attribute is required for the "img" element.

Currently, the CVLaTeX output adds a \bf in front of every title. However, this doesn't correspondingly make the formulas within the title to be bolder, thus giving a lower quality result.

It is suggested to prefix formulas with: \boldmath{}

E.g.:
https://inspirehep.net/search?ln=en&ln=en&p=arXiv%3A1701.01871&of=tlcv

{\bf ``Measurement of $\boldmath{CP}$ asymmetries in $\boldmath{D^{\pm}\rightarrow \eta^{\prime} \pi^{\pm}}$ and $\boldmath{D_s^{\pm}\rightarrow \eta^{\prime} \pi^{\pm}}$ decays''}

We currently have 2,189 authors having an arXiv ID in HEPName. arXiv, actually exposes in a nice way the arxiv ID belonging to a given author.

This is currently used only at authentication time, but we can verywell just take such information asynchronously and use it to populate the external tab and for auto claim.

A few records have a bizarre FFT%% field. For example: https://inspirehep.net/record/1094156/export/xme.

As these are incomplete FFTs they currently generate a nasty exception in DoJSON (which is expecting an s code): https://sentry.cern.ch/inspire-sentry/inspire-nightly/group/619250.

What should I do with them? Just ignore them?

Field 678__a is supposed to contain awards, but cataloguers are using notes for this instead right now because that field is not displayed.
When this is done, I will move through bibcheck all awards to 678__a where they belong.

From invenio-software/invenio#1011:
[...]
Author initials in the bibtex format should be separated by a space since a dot apparently is not considered as a separator in bibtex - resulting in suppression of the 2nd initial.
[...]

See:
https://inspirehep.net/record/1087430/export/hx

Yet another more of a question than an issue. The following query returns all Journals with a 4 or 5 letter CODEN: https://inspirehep.net/search?ln=en&cc=Journals&ln=en&cc=Journals&p=030__a%3A%2F%5E%28%5Cd%7B4%7D%7C%5Cd%7B5%7D%29%24%2F&action_search=Search&sf=&so=d&rm=&rg=25&sc=0&of=hb (in particular, there's only one record with a four letter CODEN: https://inspirehep.net/record/1212112/export/xm).

Are those okay? We are currently asserting in the schema that a CODEN has exactly 6 characters, but maybe 4/5 are okay too.

223 records say that they are 0 pages long: https://inspirehep.net/search?ln=en&p=300__a%3A%220%22. I cannot find any sensible interpretation for this, except that they are typos. What should I do with them during migration? Just discard the value of 300__a if it's <1?

The records returned by this query: https://inspirehep.net/search?ln=en&cc=Institutions&ln=en&cc=Institutions&p=510__0%3A%2F%5B%5E0-9%5D%2F&action_search=Search&sf=institutionname&so=a&rm=&rg=25&sc=0&of=hb have non-numerical values in the 510__0 field. I think those values should be removed, since they provide no value and would just complicate my DoJSON rules.

Since they are just a few, this is probably better handled by manual curation.

The following records have an ill-formatted CNUM:

• 1590071
• 1477158
• 1194030
• 980162
• 978008

The following record instead had an ill-formatted CNUM, which I fixed, but then I realized that maybe I shouldn't have, and decided to open this issue instead:

978083

CC: @annetteholtkamp @michamos

Both queries return results: https://inspirehep.net/search?cc=Institutions&p=690C_a%3A%22CORE%22, https://inspirehep.net/search?cc=Institutions&p=980__a%3A%22CORE%22, but their results do not coincide.

Here's the list of records in which they don't coincide: https://inspirehep.net/search?cc=Institutions&p=%28690C_a%3A%22CORE%22+and+not+980__a%3A%22CORE%22%29+or+%28980__a%3A%22CORE%22+and+not+690C_a%3A%22CORE%22%29

CC: @annetteholtkamp @michamos

recent portalbox re-org is not properly addressed when updating an existing install via

make install-dbchanges

....

now update portalbox value with placeholder text

echo 'from invenio.dbquery import run_sql;body = open("feedboxes/portalbox_hep_right_top.html").read();run_sql("UPDATE portalbox SET body=%s WHERE id=2", (body,))' | /usr/bin/env python
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 2] No such file or directory: 'feedboxes/portalbox_hep_right_top.html'
make: *** [reset-inspire-portalbox-configuration] Error 1

.....

@annetteholtkamp can you provide more details about what the real trouble is?

Expected behavior? Current behavior? Example?

@michamos @kaplun

so with all the latest improvements to CV LaTeX, there is still a usability issue. The link to INSPIRE record(s) displays generic text.

cvlatex.pdf

That's fine in a PDF viewer which understand links, but in printed form, this is utterly useless. How about displaying recid or doi?

INSPIRE-HEP record/1234567

instead?

Of course users could just leave \showlinksfalse whenever they want to print. Just a thought.

T.

there's a logic flaw here

https://github.com/inspirehep/inspire/blob/master/bibtasklets/bst_arxiv_doi_update.py#L389

it assumes multiple subfields a within the same 0247_ instead of multiple 0247_ each with one subfield a

T

a complete re-index uses newly created temporary tables. the table initialization uses incorrect term length for journal table. Specifically

def init_temporary_reindex_tables(index_id, reindex_prefix="tmp_"):

uses

    run_sql("""CREATE TABLE %sidxWORD%02dF (
                        id mediumint(9) unsigned NOT NULL auto_increment,
                        term varchar(50) default NULL,
                        hitlist longblob,
                        PRIMARY KEY  (id),
                        UNIQUE KEY term (term)
                        ) ENGINE=MyISAM""" % (reindex_prefix, index_id))

However, the term length for journal index was extended to accommodate long journal names, there now is

> describe idxWORD09F;
+---------+-----------------------+------+-----+---------+----------------+
| Field   | Type                  | Null | Key | Default | Extra          |
+---------+-----------------------+------+-----+---------+----------------+
| id      | mediumint(9) unsigned | NO   | PRI | NULL    | auto_increment |
| term    | varchar(255)          | YES  | UNI | NULL    |                |
| hitlist | longblob              | YES  |     | NULL    |                |
+---------+-----------------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

So this needs to be special cased

T.

Roughly 1% of the institutions have two longitudes instead of a latitude/longitude pair: https://inspirehep.net/search?ln=en&cc=Institutions&ln=en&cc=Institutions&p=034__d%3A%2F.*%2F+and+not+034__f%3A%2F.*%2F&action_search=Search&sf=institutionname&so=a&rm=&rg=25&sc=0&of=hb

This could belong to Asana (which is why I'm pinging @annetteholtkamp), but I think that a solution could be built using a script that calls a geocoding service (which is why I'm pinging @kaplun).

Hi, this is more of a question than an issue. I can't understand what are the values contained in 640__a in the Journals collection: https://inspirehep.net/search?ln=en&cc=Journals&p=640__a%3A%2F.*%2F&action_search=Search.

They definitely look like notes, but I'm not sure if they're supposed to be internal or public. They are mentioned in Twiki as "PDG-ABBREV", which I can't really decipher (https://twiki.cern.ch/twiki/bin/view/Inspire/DevelopmentRecordMarkupJournals).

@tomaszgy commented on Thu Jun 30 2016

None of the records from Jobs collection is connected by recid with an Experiment. Field 693__e contains only Experiment's name.

As in inspirehep/inspire-next#1274, would be great to have those connections.

@kaplun