Cds invenio

CDS INVENIO DÍA 1: INTRODUCCIÓN

Miguel Martín González - [email protected]

REPOSITORIOS: ¿qué son?

OBJETOS

DIGITALES

Archivar (depósito)

Preservar (METS,

PREMIS)

Difundir (OAI-PMH)

Del lat.: repositorium, significa

armario, alacena, “lugar donde se

guarda algo” [RAE]

A university-based institutional repository is a set of

services that a university offers to the members of its

community for the management and dissemination of

digital materials created by the institution and its

community members. It is most essentially an

organizational commitment to the stewardship of these

digital materials, including longterm

preservation where appropriate, as well as organization

and access or distribution

[Clifford A. Lynch (2003). Institutional Repositories: Essential Infrastructure for

Scholarship in the Digital Age. ARL Bimonthly

Report 226. http://www.arl.org/newsltr/226/ir.html]

SERVICIOS

FUNCIONES

INSTITUCIONES

PERSONAS

Partes básicas: Conceptos y glosario

Regular collections

(asociado a doctype)

Virtual collections (otra

forma de organizar

contenido)

Portalboxes (información

adicional)

CDS INVENIO DÍA 2: ESTRUCTURA GENERAL DE

FUNCIONAMIENTO Y EXPLICACIÓN DE

MÓDULOS


http://invenio-

demo.cern.ch/help/hacking/modules-

overview

Operaciones realizadas en el servidor

(privilegiadas)

ENVIO DE DOCUMENTOS: Flujo general

Interfaz de usuario

(loggeado)

ENVIO DE DOCUMENTOS: Envío mediante menú (como USUARIO

loggeado) 1de2WebSubmit is a comprehensive submission system allowing

authorized individuals (authors, secretaries and repository

maintenance staff) to submit individual documents into the

system. The submission system disposes of a flow-control

mechanism that assures the data approval by authorized units.

In total there are several different exploitable submission

schemas at a disposal, including an automated full text

document conversion from various textual and image formats.

This module also disposes of information extraction

functionality, focusing on bibliographic entities such as

references, authors, keywords or other implicit metadata.

Caso más simple: envío autorizado a TODO usuario que se valide correctamente

(sin moderación). Por ejemplo TRABAJOS ACADÉMICOS.

Login en el sistema (utilizando

los datos del correo-e)

[WEBACCESS]

Menú: Enviar

elección del tipo de documento

(doctype)

[WEBSUBMIT]


loggeado) 2de2


loggeado) 2de2Guarda

temporalmente el

envío (accesible más

tarde mediante el menú

“Sus Opciones Sus

envíos”).

NO SE COMPLETA EL

ENVIO.

Termina el envío (manda,

si procede, email a los

moderadores de contenido

asi como al autor,

informando del envío

completado).

NO aparece

inmediatamente el registro

en el Repositorio

(hay que ejecutar

manualmente las tareas

de BibSched o esperar un

tiempo prudencial –máx

1h- a que se ejecuten

automáticamente).Este número (conocido como access) es interesante para RESOLVER PROBLEMAS en el envío de los registros.

DURANTE el envío:[root@aneto cdsadmin]# find /soft -name “*1273473021_16130*"

/soft/cds-invenio/var/data/submit/storage/running/TAZ/1273473021_16130

AL FINAL del envío (después de pulsar “Terminar envío”):ç[root@aneto cdsadmin]# grep -R "TAZ-TFM-2010-018" /soft/cds-invenio/var/

Binary file /soft/cds-invenio/var/data/submit/storage/done/running/TAZ/TAZ-TFM-2010-018_20100510121914.tar.gz

matches

ENVIO DE DOCUMENTOS: RECEPCIÓN DE CORREO

ELECTRÓNICOEl usuario (submitter) y el administrador del Repositorio reciben un email indicando que el envío se ha

completado:

Este enlace indica que record number se asigna(rá) al nuevo registro.

Parte ya

explicada

ENVIO DE DOCUMENTOS: Flujo general

Procesos

internos

(bibsched)

Una vez que el usuario ha pulsado “Terminar

envío” se realizan automáticamente las

tareas explicadas hasta ahora.

Al observar Bibsched aparecerán nuevas

tareas de “BibUpload”. Ayuda sobre

BibUpload:

http://zaguan.unizar.es/help/admin/bibupload-admin-guide

Tras ser ejecutadas las correspondientes

tareas de BibUpload, se realiza la indexación

del nuevo registro (BibIndex) y éste aparece

en zaguan (WebColl):

http://zaguan.unizar.es/record/XXXX

http://zaguan.unizar.es/record/XXXX

BIBSCHED: Qué es y cómo funciona

Observar el scheduler (programador) de tareas:[root@aneto cdsadmin]# sudo -u apache bibsched

Puede funcionar en modo automático o manual (conmutable pulsando “A”). Cuando está en modo manual podemos

desplazarnos por las tareas (flechas arriba/abajo) y ejecutar una tarea en concreto (estando sobre ella, pusar “R”). En automático

(estado normal) las tareas se ejecutan solas cada cierto tiempo. Pulsando “L” sobre una tarea vemos el LOG (registro de

eventos) de la misma.

http://zaguan.unizar.es/help/admin/howto-run

BIBINDEX: Se encarga de la indexación de los datos del registro (modifica las BD‟s para que podamos encontrar ese registro cuando lo busquemos)http://zaguan.unizar.es/help/admin/bibindex-admin-guide

BIBFORMAT: Se encarga de formatear los registros y almacenar ese formateo en BD (si formato cacheado).

http://zaguan.unizar.es/help/admin/bibformat-admin-guide

WEBCOLL: Se encarga de “aglutinar” registros en Colecciones.

http://zaguan.unizar.es/help/admin/howto-run

$ webcoll -v0 -s1h

Las colecciones se definen utilizando el módulo WEBSEARCH.

[AVANZADO]

BIBRANK: Se encarga de otorgar “importancia” a los registros. Se ejecuta periódicamente sobre todos los registros. Tiene en cuenta diversos criterios.

BIBINDEX, BIBFORMAT, WEBCOLL, (WEBSEARCH, BIBRANK)

http://zaguan.unizar.es/help/admin/bibindex-admin-guideBIBINDEX: gestión de índices

Manage indexes (gestionar índices): http://zaguan.unizar.es/admin/bibindex/bibindexadmin.py

Manage logical fields (campos lógicos): http://zaguan.unizar.es/admin/bibindex/bibindexadmin.py/field

Indexes: permite

definir índices que

después se utilizarán

para la búsqueda. Un

index puede contener

uno o más logical fields.

P ej: el index collection

se puede usar para

hacer búsquedas tipo:collection:FH

Logical fields: son parte

de un index. En cada

logical field se definen

las etiquetas MARC

que se usarán para

dicho logical field.

Por ejemplo, para collection se usa la

980__% (a,b,c,…)

http://zaguan.unizar.es/admin/bibindex/bibindexadmin.py

http://zaguan.unizar.es/help/admin/bibformat-admin-guideBIBFORMAT: gestión de formatos

Output formats: definen los distintos formatos de salida para los registros del Repositorio

/record/XXX?of=CODIGO&verbose=9


Output formats: definen los distintos formatos de salida para los registros del Repositorio

/record/XXX?of=CODIGO&verbose=9

BORRADO DE CACHÉ:

echo "DELETE FROM bibfmt WHERE format='hb'" | /soft/cds-invenio/bin/dbexec

echo "DELETE FROM bibfmt WHERE format='HB'" | /soft/cds-invenio/bin/dbexec

ACTUALIZACIÓN DE CACHÉ:

Now suppose you don‟t want to delete the information, but only to update the cache information. Then you should type:

sudo -u apache /soft/cds-invenio/bin/bibreformat –a

If you only want to update a collection‟s output format you should type:

sudo -u apache /soft/cds-invenio/bin/bibreformat -c “Fondo Histórico”.

Note that the -c parameter value must be the name of desired collection which can be seen in websearch admin screen:$YOUR_SITE_NAME/admin/websearch/websearchadmin.py?colID=1&mtype=perform_showall


Output formats: definen también REGLAS tipo firewall sobre qué plantilla aplicar …

Por ejemplo, para el

formato HTML

BREVE (HB) se

definen las siguientes

reglas.

Si la etiqueta 980.a

del registro es igual a

„PICTURE‟, entonces

usa el TEMPLATE

„Picture HTML brief‟.

¿Qué es un

TEMPLATE? Es una

PLANTILLA de

FORMATO.


Output templates:

Cada PLANTILLA

DE FORMATO

está compuesta

por un conjunto

de <tokens>.

Cada <token>

muestra el valor

de una de las

etiquetas.


Output templates: cada token se “traduce” en un fichero .py (Python) del sistema.

[root@zaguan cdsadmin]# find /soft -name "*bfe_authors*"

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art.pyc

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_book.py

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art.py

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_book.pyc

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_tesis.py

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors.pyc

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art2.py

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_tesis.pyc

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors.py

/soft/cds-invenio/lib/python/invenio/bibformat_elements/bfe_authors_art2.pyc

http://zaguan.unizar.es/help/admin/websearch-admin-guide?ln=esWEBCOLL (WEBSEARCH): gestión de colecciones

Una

colección

puede ser

REGULAR

o VIRTUAL.

Las

colecciones

con relación

REGULAR

aparecen

en la parte

izquierda

del

Repositorio.

Las

colecciones

con relación

VIRTUAL

aparecen

en la parte

derecha.

http://zaguan.unizar.es/help/admin/websearch-admin-guide?ln=esWEBCOLL: gestión de colecciones

Una colección se define como una QUERY (consulta/búsqueda). Usualmente se

hace contra el índice collection (referencia a la 980__%).

Por ejemplo, todos los registros que tengan 980__%=TAZ (equivale a

collection:TAZ).

A la colección se le da un ID y un nombre (translation). Es conveniente que sean

iguales.

Portalboxes = código HTML que se muestran en el lateral / zona inferior de la

http://zaguan.unizar.es/help/admin/websearch-admin-guide?ln=esWEBCOLL: portalboxes

Forzar actualización de portalboxes o la

actualización de webcoll en general:

webcoll --force

MANUAL (modo colaborativo)VALIDACIÓN

(Personal BUZ)

AUTOMÁTICO (Harvesting)

Importación desde otros

Catálogos/repositorios

ARCHIVAR: ¿cómo se almacena la información?

Flujo de trabajo en el modelo de Open Access.

ROL = conjunto de

usuarios (admite

expresiones regulares).

Definición tipo firewall:

allow email

“[email protected]”

deny any

WEBACCESS: gestión de roles, autorizaciones,

etc

GUIA PARA EL ADMINISTRADOR:

http://zaguan.unizar.es/help/admin/webaccess-

admin-guide

GUIA PARA EL PROGRAMADOR:

http://invenio-

demo.cern.ch/help/hacking/webaccess-

internals

ACCIÓN = conjunto de

operaciones que se

pueden realizar en el

Repositorio

(submit), (referee),

(runcfgxxx) ,…

AUTORIZACIÓN = regla que relaciona ROLES con ACCIONES

mailto:[email protected]

http://zaguan.unizar.es/help/admin/webaccess-admin-guide





http://invenio-demo.cern.ch/help/hacking/webaccess-internals





¡EL COMPORTAMIENTO POR DEFECTO NO

ES EL QUE SE DICE EN LA AYUDA!

The default behaviour (at least in recent versions) is to

authorize users to submit if there is no

authorization specifically defined (i.e. a role

connected to an action).

The action becomes restricted for "everybody" as

soon as you add an authorization for the given

submission and action.

So if you don't add an authorization for doctype=TAZ,

act=SRV (even with an empty role), anybody can use

this action. To review who used this submission (and

check if they were authorized) your can run:

$ echo "SELECT * from sbmSUBMISSIONS where doctype='TAZ' and \

action='SRV'" | /opt/cds-invenio/bin/dbexec

WEBACCESS: comportamiento POR DEFECTO.



admin-guide


http://invenio-


internals












etc



admin-guide


http://invenio-


internals












etc



admin-guide


http://invenio-


internals

cfgXXX = configurar XXX

módulo. [AVANZADO]

runYYY = ejecutar

determinada tarea de

bibsched. Salvo

runbibedit, el resto NO

tocar.

Submit: enviar

documentos (SBI, MBI,

APP, SRV)

Referee: a quién se avisa

para moderar.

Submit APP vs Referee:

el primero define quién

puede, y el segundo a

quién se avisa.











MANUAL (modo colaborativo)VALIDACIÓN

(Personal BUZ)

AUTOMÁTICO (Harvesting)

Importación desde otros

Catálogos/repositorios

ARCHIVAR: ¿cómo se almacena la información?

Flujo de trabajo en el modelo de Open Access.

ARCHIVAR – Ejemplo: Harvesting de CERN

bibharvest -vListRecords

-f2009-12-01

-pmarcxml

-o/home/cdsadmin/harvestCERN20091201.txt

http://cdsweb.cern.ch/oai2d

http://www.openarchives.org/pmh/tools/tools.php

DIFUNDIR: Acceso a servidor web (http://zaguan.unizar.es)

- Herramientas usuales de búsqueda

- Búsquedas por colección o por otros criterios personalizables

- Establecimiento de grupos (comunidades)

- Herramientas de seguimiento (cestas)

http://zaguan.unizar.es/

DIFUNDIR: Acceso OAI (http://zaguan.unizar.es/oai2d)

OAI = Open Access Initiative

(iniciativa de acceso abierto)http://www.openarchives.org

- Protocolo para máquinas

- Maximizar y simplificar difusión

- Evitar replicación de contenidos

Ejemplos query OAI:

Identificar repositorio:http://zaguan.unizar.es/oai2d?verb=Identify

Listar setshttp://zaguan.unizar.es/oai2d?verb=ListSets

Obtener formatos de metadatoshttp://zaguan.unizar.es/oai2d?verb=GetRecord&metadataPref

ix=oai_dc&identifier=oai:zaguan.unizar.es:100

Obtener un registro en un formato

determinadohttp://zaguan.unizar.es/oai2d?verb=GetRecord&metadataPref

ix=oai_dc&identifier=oai:zaguan.unizar.es:100

Más ejemplos de query’s soportadas:http://www.leccionespracticas.com/cds-invenio/oai-pmh-verb-

parameters/

http://zaguan.unizar.es/oai2d?verb=Identify

http://zaguan.unizar.es/oai2d?verb=ListSets

http://zaguan.unizar.es/oai2d?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:zaguan.unizar.es:100




http://zaguan.unizar.es/help/admin/bibharvest-admin-guide#3

http://www.leccionespracticas.com/cds-invenio/cds-invenio-

understanding-oai-setspecs-collections-and-phrases

OAI server: cómo configurar un SET

The first two fields (setSpec and

setName) are the ways to identify

your new set. First one is the

machine-readable name and the

second, the human-readable one.

Usually I type the same name in

both fields.

In my example I will type „public‟

in these fields.

The next field is Collection(s).

Here you must type the

Collection(s) to which belong the

records you want to add to the

OAI. For instance, I have a

collection called “Tesis” so I type

“Tesis” in this field. Please note

this name is exactly the one

displayed in WebSearch admin

interface when listing the

collections. This is NOT the

value you use to define a

collection (see images below).

From now on I‟ll call the first

Collection Names and the second

Collection Queries.

http://zaguan.unizar.es/help/admin/bibharvest-admin-guide





http://www.leccionespracticas.com/cds-invenio/cds-invenio-understanding-oai-setspecs-collections-and-phrases




















OAI server: cómo configurar un SET

Next fields are Phrases. I was

wondering how this Phrases

and collections were evaluated.

This is the way it works:

1) the union of the Collection(s)

you specified is taken (let‟s call it

A).

2) on this you apply the (at most)

three condition reading them from

left to right. So e.g. if you have “X

and Y or Z” phrase‟s, all the

records from A that match X are

intersected with all the records

from A that match Y. Then this is

united with all the records from A

that match Z.

TIPS:1) If you want to add a phrase which involves a concrete field

(ie:984) you should make sure it is already defined. To do this

refer to:

http://yourURLToCDSINVENIO/admin/bibindex/bibindexadmin.p

y/field. If it is not defined there, add the definition.

2) If you want to add a phrase which involves collections you

should use the „Collection Query‟. This is, in this case I would

use “THE” instead of “Tesis”, as “Tesis” collection is defined like

collection:THE (refer to previous section for further explanation).


























OAI server: ejemplo de definición de SET complejo

Let‟s suppose you want to define a OAI set, called „public‟, which involves Collection (names) A,B,C and

only some of the records in collection (name) D, this is an OAI set is defined as a union of definitions.

The records belonging to collection D must be included only if the 984a field contains exactly the word

“public”.

What you can actually do is:

(i) define a first “public” setSpec with:

Collection(s): A,B,C

(ii) define a second “public” setSpec with:

Collection(s): D

Phrase: public 984__% Exact phrase























REPOSITORIOS: ¿qué son?

OBJETOS

DIGITALES

Archivar (depósito)

Preservar (METS,

PREMIS)

Difundir (OAI-PMH)

Del lat.: repositorium, significa

armario, alacena, “lugar donde se

guarda algo” [RAE]

A university-based institutional repository is a set of

services that a university offers to the members of its

community for the management and dissemination of

digital materials created by the institution and its

community members. It is most essentially an

organizational commitment to the stewardship of these

digital materials, including longterm

preservation where appropriate, as well as organization

and access or distribution

[Clifford A. Lynch (2003). Institutional Repositories: Essential Infrastructure for

Scholarship in the Digital Age. ARL Bimonthly

Report 226. http://www.arl.org/newsltr/226/ir.html]

SERVICIOS

FUNCIONES

INSTITUCIONES

PERSONAS

Buenas prácticas y requerimientos

USO de formatos estándar ( texto, video,

sonido, imágenes)

Descripción bibliográfica:

DC, MARCXML, METS

Adaptación a los cambios tecnológicos

El COSTE de la preservación

Preservar es caro (recursos humanos, recursos

informáticos…)

¿Hay que preservarlo todo? ¿qué debemos preservar?

PREMIS

PRESERVAR: ¿cómo se almacena la información para asegurar que SIEMPRE

estará disponible?

http://www.loc.gov/standards/premis/

CDS INVENIO DÍA 2: DEFINIENDO UN NUEVO DOCTYPE

CON WEBSUBMIT


PASO 0: Consideraciones previas

Almacenar sí vs Almacenar no:- ¿Es interesante almacenar este nuevo “tipo de documento”?

- ¿Qué volumen de envíos de este tipo podría producirse si se implementa?

- ¿Qué volumen de consultas?

Preservar sí vs Preservar no:- ¿Interesa preservarlo?

- ¿Cuál va a ser el coste de preservarlo?

- ¿Cuál va a ser la FORMA de preservarlo?

- ¿Cuánto tiempo?

PERMISOS / DERECHOS de autor: - ¿quién va a poder enviar?

- ¿va a ser un envío moderado?

- De ser moderado, ¿Quién lo va a validar?

- ¿Quién lo va a poder CONSULTAR?

- ¿A texto completo o solo los metadatos?

PASO 1: Buscando el MARC más completo posible

PASOS:

• ¿Es un nuevo “tipo” de documento o “encaja” en alguna subcategoría de los

existentes? Aunque no “encaje” en subcategorías, ¿cómo se guardan los datos

SIMILARES? (P ej, si va a tener keywords y hay otros doctypes con keywords,

¿cómo se guardan? ¿dónde se guardan?)

• ¿Cómo se procede en otros repositorios para almacenar este tipo de

contenido? ¿Qué tipo de FORMATO es el más conveniente para almacenar este

tipo de documento? ¿Va a ser el hosting LOCAL o REMOTO (=cargar fichero o

añadir URL)?

• ¿Qué información (metadatos) es ESENCIAL que contengan los registros de

este “tipo”?

• ¿Qué información (metadatos) podría contener este “tipo” de documento, pero

no es imprescindible?

PASO 1: Buscando el MARC más completo posible

PASOS:

-Definir un “modelo” en MARC teniendo en cuenta el registro con más metadatos

que exista. Por ejemplo:

<record>

<controlfield tag="001">4574</controlfield> ESTOS DATOS LOS GENERARÁ EL

<datafield tag="037" ind1=" " ind2=" "> SISTEMA. NO hay que pensar cómo

<subfield code="a">TESIS-2010-039</subfield> generarlos

</datafield>

<datafield tag="041" ind1=" " ind2=" ">

<subfield code="a">spa</subfield>

</datafield>

<datafield tag="100" ind1="1" ind2=" ">

<subfield code="a">Sáenz Preciado, Jesús Carlos</subfield>

</datafield>

<datafield tag="245" ind1="0" ind2="0">

<subfield code="a">La Terra Sigillata Hispanica del Municipium Augusta Bilbilis</subfield>

</datafield>


<subfield code="b">Universidad de Zaragoza</subfield>

<subfield code="a">Zaragoza</subfield>

<subfield code="c">1997</subfield>

</datafield>


<subfield code="a">990</subfield>

</datafield>

…

</record>

PANTALLA CONFIG. doctype (WEBSUBMIT)

Acciones: definen el tipo de

formulario que se creará:

APP = APProval

SBI = SuBmIt

MBI= Modify

SRV = Submit files

Se empieza definiendo la

INTERFAZ de envío de nuevos

documentos (para la acción

SBI).

Familiarizarse con los

ELEMENTS existentes en el

sistema.

PANTALLA CONFIG. doctype (WEBSUBMIT)

View INTERFACE (formulario

HTML)

View FUNCTIONS

(operaciones a ejecutar y orden

de las mismas)

PASO 2: DEFINIR FORMULARIOS DE ENVÍO

PASOS:

- Ya tenemos los DATOS que hay que solicitar al usuario = sabemos qué campos

son necesarios. También sabemos si son opcionales u obligatorios. Hay que

pensar en QUÉ hay que validar sobre esos datos (p. ej: si es fecha, que sea

formato DD/MM/AAAA y que fecha insertada sea anterior a la actual).

- Nos fijamos cómo están definidos los formularios de OTROS doctype ¡¡SIN

MODIFICARLOS!!

.


Un formulario = conjunto de ELEMENTS, LABEL‟s, LEVEL‟s y CHECK‟s.

ELEMENT = aglutina el TIPO DE <INPUT> y el MARCCODE asociado.

LABEL = modificador HTML que se coloca PRECEDIENDO a cada ELEMENT.

LEVEL = O:optional, M:mandatory

CHECK = Función JS a aplicar al <input> (por ejemplo, DateCheck)


Veamos el ELEMENT llamado „DEMOBOO_TITLE‟

PASO 3: DEFINIR LAS FUNCIONES QUE SE EJECUTAN TRAS EL ENVIO

[AVANZADO]Dos casos básicos: (1) Envío MODERADO (2) Envío SIN MODERAR.

EJEMPLO: (1)


[AVANZADO]Para cada Function ajustamos los PARAMETERS.

.

Eliminar la función

“move to done” es

muy útil para hacer

un DEBUG cuando

se produce algún

tipo de problema

con los envíos.


[AVANZADO]Estos ficheros son los más IMPORTANTES. Indican cómo debe crearse el registro (la equivalencia

entre ELEMENTS y el MARCXML del registro que se creará)

.

[root@zaguan cdsadmin]# find /soft -name DEMOTHE.tpl

/soft/cds-invenio/etc/bibconvert/config/DEMOTHE.tpl

PASO 4: Crear la COLECCIÓN REGULAR para el nuevo doctype

Ya tenemos todos los pasos hechos para poder realizar envíos de nuevos registros.

El valor que hemos puesto (de forma estática) para la colección (en el

MARCTAG 980__a) define la query que deberemos asignar a la

colección.

En este caso: “collection:TESIS”


Lo único que falta es crear (si procede) la nueva colección que agrupe estos registros nuevos.

Para definir una nueva

colección se usa el

módulo WebSearch.

“Create new collection” y

nos pide el “Default

name”


Vamos a ver los pasos y valores necesarios para definir la nueva colección…

Para definir una nueva

colección se usa el

módulo WebSearch.

“Create new collection” y

nos pide el “Default

name”

Después se selecciona la

“Parent collection” y la

“Relationship”.


La colección ya está definida. Ahora hay que editarla y añadirle la QUERY necesaria para que

funcione… La misma cadena que hemos usado en el DEMOTHEcreate.tpl la

ponemos como query en el campo de “Modify collection query for collection

‘ejemplo‟”


La colección (y su query asociada) están completamente definidas, ¿cómo sigo?

La nueva colección aparece pulsando “Show all”,

pero NO aparece aun en la página principal.

¿Cómo hacer que aparezca? Hay que esperar a la

ejecución de webcoll en bibsched (si está en modo

automático) o ejecutar manualmente la tarea webcoll

en bibsched (R). Si pese a todo no se actualiza, se

puede forzar manualmente:

[root@aneto cdsadmin]# sudo -u apache webcoll --force

WebColl Task Submission

=======================

Username: [email protected]

Password:

PASO 5: VERIFICAR QUE LOS NUEVOS REGISTROS APARECEN EN LA

NUEVA COLECC.La colección está totalmente definida. Si enviamos un registro debería

aparecer dentro de su colección.

¿Qué hacer si no aparece?

1. Acceder al registro, a su visualización XM (marcxml) y verificar que la

980__a contiene la MISMA CADENA de texto que contiene la query de

la colección.

2. Ejecutar manualmente las tareas de bibsched (todas dos veces).

3. Actualizar la página.

PASO 6: GESTIONAR LOS PERMISOS CON WEBACCESS

Los envíos funcionan. Los registros aparecen dentro de su colección.

Falta definir PERMISOS.

- Crear ROL (si no existe ya uno apropiado para tal fin)

- Crear autorizaciones (qué acciones puede hacer cada rol)

- Verificar el funcionamiento.

Technology

Cds invenio