inspirehep / inspire Goto Github PK
View Code? Open in Web Editor NEWOfficial repo of the legacy INSPIRE-HEP overlay
Home Page: http://projecthepinspire.net
Official repo of the legacy INSPIRE-HEP overlay
Home Page: http://projecthepinspire.net
INSPIRE git repository ---------------------- INSPIRE sources are to be installed after the Invenio sources. You can customize some things in config-local.mk, for example on Debian GNU/Linux, use: $ cat config-local.mk INSTALL = install -g www-data -m 775 To install a small INSPIRE demo site from scratch, you can use for example `inspire-recreate-demo-site' helper devscript, see instructions at: <https://github.com/tiborsimko/inspire-devscripts#inspire-recreate-demo-site> You may be interested in having an RSS feed update a box on your homepage. If so, edit feedboxes/inspire_update_feedboxes.py with a valid FEEDS list, then install it somewhere and call it with the -d flag every ten minutes or so. It will rely on webcoll to regenerate the home page, so it's not really sensible to run it more often than webcoll runs. Required Python packages can be installed by running: $ pip install -r requirements.txt - end of file -
so with all the latest improvements to CV LaTeX, there is still a usability issue. The link to INSPIRE record(s) displays generic text.
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.
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.
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.
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 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 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.
recent portalbox re-org is not properly addressed when updating an existing install via
make install-dbchanges
....
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
.....
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).
The following records have an ill-formatted CNUM:
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
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?
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).
@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.
@annetteholtkamp can you provide more details about what the real trouble is?
Expected behavior? Current behavior? Example?
spires allows the search "find eprint HEP-TH 9304057" whereas Inspire demands a slash. That causes eprint searches via easy search to fail.
Now that trac-128 is in Invenio/master and old-inspire/master, the corresponding patch needs to go into new-inspire/master.
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''}
My beloved wife reports that it's currently technically difficult to remove comments from our LaTeX output formats. E.g.:
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)
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
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).
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.
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.
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!
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.
Given a DOI prefix we could export the ORCID DOI association.
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.
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.
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.
pull the newly merged invenio and creat a new dep branch on tislnx1 and install it
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.
[...]
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.
Just in case we decide not to use Invenio trac instance, we might like to consider:
A few records have a bizarre FFT%%
field. For example: https://inspirehep.net/record/1094156/export/xme.
As these are incomplete FFT
s 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?
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?
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 :-)
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?
@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.
The newly introduced prodsync
bitasklet (see #122) should be amended to:
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 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.
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.
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
Just a reminder 😃
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).
@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!
[...]
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:
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.
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
)
[...]
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.
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
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"
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).
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.
continent
be an array, so that I can accomodate all the records with a /
?Middle East
? Is it too contentious to just use Asia
for it?A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.