Projecte

General

Perfil

Accions
Historial

Trobar el registre del DDD a partir del de Fènix

Aquest document descriu diferents maneres que es poden utiltizar pels gestors de la recerca de la UAB per trobar a quin número de registre del DDD corresponen els identificadors de Fènix (activitat-comptador).

Vist amb perspectiva, és un document excessivament llarg, però a algunes d'aquestes solucions hi hem arribat després de considerar les anteriors. La fórmula recomanada és la del final del document, de manera que els lectors no interessats en les alternatives poden saltar-se-les.

Ferran Jorba
Juny 2012

1. Codificació en Marc21

Al DDD mantenim els identificadors externs dels registres que obtenim de fonts externes. Seguint el estàndard Marc21, els posem a l'etiqueta 035 (http://www.loc.gov/marc/bibliographic/bd035.html).

Els identificadors de Fènix els manenim com a activitat-comptador (ex., ARE-53879). Al DDD hi afegim l'identificador recercauab com a identificador extern. En Marc21:

035 __ $9 recercauab $a ARE-53879

Compte que aquesta etiqueta 035, a més dels identificadors de Fènix, en posem d'altres. Els de Fènix estan identificats per un $9 recercauab.

2. Com cercar les equivalències via http

2.1. Introducció

Hi ha vàries maneres de tenir l'equivalència. Com a usuari final, fent la cerca porta directament al registre:

Per eliminar alguna hipotètica ambigüetat, hi podem afegir recercauab:

El resultat el podem formatejar de moltes maneres amb el paràmetre of (output format), per exemple:

El mateix passa si en comptes d'un sol registre el resultat és d'un conjunt de registres, per exemple:

El format tm (text marc) permet, a més, perfilar quina etiqueta volem via paràmetre ot (output tag). Per exemple, si només ens interessa la 035, podem fer:

Si volessim més d'una etiqueta, la posariem a continuació, separades per coma. Per exemple, el títol és la 245:

Per defecte, Invenio dóna el resultat de 10 en 10. Això es pot canviar de dues maneres: en les preferències en el compte personal, o bé amb el paràmetre rg (result group). P. ex, si en volem 100:

Si els volem tots, podem demanar-ne 99999, per exemple:

Tots els paràmetres estan documentats en aquesta pàgina:

2.2. Com gestionar les cerques ambigües

Si la cerca exacta no dóna resultat, Invenio procura fer una booleana amb les parts corresponents. Un exemple simplificat és aquest (en aquest exemple no hi poso recercauab, justament perquè pugui donar un resultat ambigu):

El text explicatiu ja ajuda a la persona que ho consulta què està fent, però si demanem només l'identificador, el text no apareix i per tant podria ser erroni:

En general, si hi afegin recercauab no hauria de passar, però la manera d'evitar les cerques alternatives és amb el paràmetre ap (alternative patterns). Per desactivar-lo, cal passar un ap=0 a la URL:

Finalment, doncs, la URL específica seria:

En Invenio, cercar en majúscules com minúscules no afecta el resultat (com posar-hi accents o no, encara que en aquest cas no és aplicable). Finalment, recordeu que l'ordre dels paràmetres és irrellevant, de manera que també pot ser així, si resulta més fàcil de construir

3. Com cercar les equivalències via dict

Per al DDD, a més de la consulta via http, també oferim una consulta equivalent via el protocol dict. Podeu consultar sobre dict i el seu protocol a múltiples llocs d'Internet, per exemple:

Hi ha també una extensió de Firefox que permet fer cerques via protocol dict: http://dict.mozdev.org/

L'avantatge de fer-ho en dict és la velocitat, degut a la simplicitat de la seva implementació respecte a una aplicació molt més complexe com Invenio. A més a més, la implementació de referència (la de dict.org) és madura i fa molts anys que s'està optimitzant i pulint (https://www.ohloh.net/p/7381). Si via http les cerques es resolen en dècimes de segon, via dict és en milèssimes quan el resultat és positiu. Quan el resultat és negatiu (no trobat), és força sensible a fer la cerca en un diccionari (taula) concret o en genèric. Si es fa en el diccionari concret, és lleugeríssimanent més lent, encara que es manté en les milèssimes de segon. Si la cerca es fa genèrica, passa a centèssimes de segon. Aquest matís és importat, com veurem, si s'acaben fent desenes de milers de cerques d'una manera periòdica.

Rendiment via http:

$ time wget --quiet -O - "http://ddd.uab.cat/search?ap=0&of=id&p=recercauab+are-53879" 
[60765]

real    0m0.435s
user    0m0.000s
sys    0m0.004s

Rendiment via dict, amb resultats positius:

$ time dict -h ddd.uab.cat are-53879
1 definition found

From Recerca (Fenix) to DDD recid [recercauab2recid]:

  60765

real    0m0.004s
user    0m0.004s
sys    0m0.000s

$ time dict dict://ddd.uab.cat/d:are-53879
1 definition found

From Recerca (Fenix) to DDD recid [recercauab2recid]:

  60765

real    0m0.004s
user    0m0.004s
sys    0m0.004s

Rendiment via dict, amb resultats negatius:

$ time dict -h ddd.uab.cat ARE-abcdef
No definitions found for "ARE-abcdef" 

real    0m0.039s
user    0m0.004s
sys    0m0.000s

$ time dict -h ddd.uab.cat -d recercauab2recid ARE-abcdef
No definitions found for "ARE-abcdef" 

real    0m0.007s
user    0m0.000s
sys    0m0.000s

Els resultats són indepenents del client. Per exemple, el mateix client curl sap interrogar amb els dos protocols:

$ time curl "http://ddd.uab.cat/search?ap=0&of=id&p=recercauab+are-53879" 
[60765]
real    0m0.437s
user    0m0.008s
sys    0m0.000s

$ time curl dict://ddd.uab.cat/d:are-53879
220 homs.uab.es dictd 1.11.2/rf on Linux 2.6.32-5-amd64 <auth.mime> <29.29527.1338813531@homs.uab.es>
250 ok
150 1 definitions retrieved
151 "are-53879" recercauab2recid "Recerca (Fenix) to DDD recid" 
60765
.
250 ok [d/m/c = 1/0/11; 0.000r 0.000u 0.000s]
221 bye [d/m/c = 0/0/0; 0.000r 0.000u 0.000s]

real    0m0.007s
user    0m0.008s
sys    0m0.000s

Per al DDD, utilitzem el servidor canònic (el de dict.org), concretament tal com està empaquetat per a Debian (http://packages.debian.org/dictd). El port del servidor dict és l'estàndard (2628) i està obert a tot el món, sense restriccions. El diccionari (taula) específic pels identificadors de fènix és la recercauab2recid. D'altra banda, el protocol dict, i al seu torn els servidors dict, acostumen a permetre cerques aproximades. Per tant, si volem fer una cerca específica equivalent a la http anterior, seria així:

  • dict://ddd.uab.cat/d:are-53879:recercauab2recid:exact

Amb el client dict canònic (el de dict.org), que permet les dues sintaxis:

  • $ dict dict://ddd.uab.cat/d:are-53879:recercauab2recid:exact
  • $ dict --host ddd.uab.cat --database recercauab2recid --strategy exact are-53879
  • $ dict -h ddd.uab.cat -d recercauab2recid -s exact are-53879

Cal consultar la implementació del client corresponent, en Python, Perl, Ruby, PHP o Java, per la sintaxi específica.

4. Sobre la diferència de velocitat entre les cerques via http o dict

Pel que hem vist, estem parlant de resultats que són, de mitjana, 100 vegades més ràpids a favor del dict. Per una cerca puntual, per unes dotzenes o per uns centenars, això és força irrellevant. Però quan fem desenes de milers, com el volum del que estem parlant per Fènix, sí que ho és. Si via http ho resol en mig segon i via dict en 7 milèssimes (perquè majoritàriament el resultat serà negatiu), per 60.000 cerques, fem números:

  • 60.000 cerques x 0,5 segons = 30.000 segons = 500 minuts = 8,3 hores
  • 60.000 cerques x 0,007 segons = 420 segons = 7 minuts

Passar de 8 hores llargues a 7 minuts justos és molt rellevant.

5. Cal fer cerques?

5.1. Escollir l'estratègia per a cada cas: cerques puntuals o actualitzacions batch de la base de dades

Si del que es tracta és de fer una consulta puntual, per exemple, en el moment de visualtizar un registre i consultar si el tenim al DDD, tan és utillitzar una cerca http com dict.

Però si del que es tracta és de de fer una cerca sistemàtica, millor pensar bé l'estratègia abans de posar-s'ho. Vegem.

Si Fènix té, aproximadament, uns 60.000 registres i al DDD ara en tenim 359, encara que en els propers mesos hi sumem uns quants centenars, milers, o fins i tot dotzenes de milers, fer una cerca per a cadascun dels registres donarà bàsicament resultats negatius. I els donarà mentre hi hagi més registres de Fènix que no són al DDD que no a l'inrevés, situació que no canviarà en els propers anys. Fer desenes de milers de cerques per saber que em la majoria dels casos no trobarem resultat és malbaratar recursos de tota mena, enlentint també el DDD durant tota questa estona, i allargar el procés durant hores (si es fa per http) o, en el millor dels casos, minuts (per dict). Si és via dict, al menys, no afectaria ni el servidor Apache ni la base de dades MySQL.

Hi ha una altra opció, que ja hem exposat més amunt. Revisem-la ara a la llum de la magnitud de les xifres. Comparem el resultat amb obtenir tots el que tenim de Fènix al DDD:

$ time wget --quiet -O fenix.ddd "http://ddd.uab.cat/search?p=recercauab&of=tm&ot=035&rg=99999" 

real    0m0.719s
user    0m0.000s
sys    0m0.016s

És a dir, en menys d'un segon ja els tenim tots! En comptes de preguntar un per un, és millor obtenir-los tots, i a partir d'aquí, informar la base de dades de Fènix de les existències trobades. Resumint:

  • 60.000 cerques x 0,5 segons = 30.000 segons = 500 minuts = 8,3 hores
  • 60.000 cerques x 0,007 segons = 420 segons = 7 minuts (quasi 100 vegades més eficient que la primera)
  • 1 cerca x 1 segon = 1 segon (més de 400 vegades més eficient que la segona, i 30.000 vegades més eficient que la primera)

Per tant, si hem de fer cerques, aquesta és òbviament la implementació preferible!

5.2. Lliçons apreses en les deteccions del 2011

L'estiu del 2011, ja vaig fer una operació comparable a aquesta, seguint diferents estratègies, a base de prova i error, que estan escrites a la tasca #1245. Va ser aleshores quan vaig veure que la cerca bruta i sistemàtica no portava enlloc, perquè tota l'operació s'eternitzava durant hores i hores. Vaig seguir dues vies:

  1. Mirar d'estalviar cerques inútils. Es tractava de fer dos grans grups: els articles que potencialment hi podien ser i els que d'entrada ja sabem que no hi seran. Pensant una mica, vaig veure que podia ser per revista: tal com escric a la tasca #1245, només faig la cerca si d'aquella revista tenim algun article al DDD; si no, no cal ni intentar-ho. És a dir, abans de començar, obtinc una llista dels ISSNs que existeixen al DDD i l'utilitzo per a discriminar-los. Potser aquesta lliçó també pot servir ara?
  2. D'altra banda, vaig ressucitar la meva antiga experiència amb dict, perquè recordava la seva espectacular eficiència. Potser a la llarga resultarà útil per més casos.

6. Recomanació final: no fer consultes sinó carregar dades exportades

Hi ha encara una altra opció: girar l'estratègia. En comptes de fer cerques al DDD, es tractaria de recollir les dades del DDD ja exportades en un format fàcil d'utilitzar, i actualitzar a partir d'ella la base de dades de recerca.

Experimentalment, he creat un directori http://ddd.uab.cat/data/ (he utilitzat deliberadament aquest nom per donar-nos un toc de modernitat, que sembla que vesteix molt) on hi podem deixar dades exportables, en fitxers pensats per ser importats i exportats fàcilment. En el cas que ens ocupa, els he deixat a http://ddd.uab.cat/data/recercauab/ i el fitxer es diu http://ddd.uab.cat/data/recercauab/recercauab2recid.csv.

El format del fitxer hem pactat que sigui sense capçalera i amb els dos valors separats per coma, i sempre només hi haurà dos camps, l'identificador de Fènix i el del DDD, en aquest ordre. En cas que algun dels dos valors es repeteixi (tingui una segona parella), hi haurà un segon registre amb el valor repetit i la seva altra equivalència. L'actualització és diària, entre les 22h i mitjanit.

Actualitzat per Ferran Jorba fa més de 13 anys · 53 revisions