Cámara de Senadores: de fuente hostil a dataset validado
La Cámara de Senadores publica información suficiente para reconstruir una parte importante de su vida parlamentaria, pero no la entrega como un dataset estable.
La fuente existe. Es pública. Tiene valor institucional. Pero no se comporta como una base de datos.
El trabajo de camara-senadores-mex parte de esa fricción: convertir una fuente institucional hostil en un dataset senatorial validado. No por confianza ciega en el portal, sino por reconstrucción: localizar la señal, extraerla bajo restricciones, persistirla en una estructura consultable y auditar los vacíos que la propia fuente deja.
Esta página no es un manual de uso del repositorio. Es una lectura reconstructiva del proceso: cómo una publicación diseñada para navegación humana se convierte en evidencia legislativa procesable.
| Fuente | Proceso | Persistencia | Auditoría | Contrato |
|---|---|---|---|---|
| portal institucional | extracción | SQLite | validación read-only | contrato senatorial |
El problema: una fuente oficial no es lo mismo que un dataset
El portal del Senado ofrece páginas, tablas, perfiles y documentos. Pero una publicación oficial no equivale automáticamente a un dataset.
Un dataset necesita estabilidad, campos reconocibles, reglas de pertenencia, trazabilidad y criterios de validación. La fuente institucional, en cambio, aparece como una combinación de HTML, rutas numéricas, vistas parciales, metadatos incompletos y respuestas que no siempre son homogéneas.
La tarea no consiste entonces en “descargar datos”. Consiste en reconstruir una fuente.
Eso implica distinguir contenido sustantivo de navegación, separar evidencia directa de inferencias, contar ausencias y evitar que la limpieza de datos borre señales importantes sobre la fragilidad de la fuente original.
/66/: la primera pista estructural
Dentro del sitio institucional, la ruta /66/ funciona como una puerta de entrada a la LXVI Legislatura.
No es una API. Tampoco es, por sí sola, una garantía de completitud. Pero sí ofrece una pista estructural: el sitio organiza parte de su publicación alrededor de identificadores de legislatura.
En una fuente hostil, cada patrón estable importa. Un número en la URL, una jerarquía repetida, un bloque de navegación o una convención de enlaces pueden convertirse en anclas para reconstruir el universo documental.
/66/ funciona así: menos como destino final y más como punto de partida para mapear qué contenidos legislativos están agrupados bajo esa convención.
/66/
┌───────┼────────┐
│ │ │
legislatura votaciones páginas relacionadasPor qué el HTML no basta
El HTML institucional es la primera evidencia, pero no alcanza como dataset final.
Puede contener nombres, fechas, cargos, tablas, enlaces y textos útiles. También puede contener navegación, estilos, bloques repetidos, información lateral, fragmentos incompletos o marcas cuya semántica depende del contexto visual.
Leer el HTML permite detectar señales. Validarlo exige más: identificar qué campo viene declarado por la fuente, qué campo se infiere, qué contenido se repite por plantilla y qué piezas no pueden auditarse con el mismo nivel de confianza.
Por eso el proyecto no trata al HTML como base final. Lo trata como fuente primaria.
El dataset aparece después: cuando cada extracción se normaliza, cada vacío queda contado y cada regla de transformación puede ser revisada.
La tabla escondida: viewTableVot.php
El punto de entrada práctico para las votaciones nominales es una vista AJAX: viewTableVot.php.
Esa vista entrega fragmentos HTML con registros de votación. No es una descarga abierta, estable y autocontenida. Es una pieza de interfaz: una respuesta parcial pensada para alimentar una tabla dentro del sitio.
Ahí está una parte fundamental de la señal: legisladores, sentido del voto, partido y contexto de votación. Pero aparece encapsulada en una forma que obliga a reconstruir.
La fuente institucional publica datos, pero no garantiza por sí misma las condiciones de extracción, trazabilidad ni completitud que exige un dataset reproducible.
<tr>
<td>Sen.</td>
<td>María Ejemplo</td>
<td>Grupo Parlamentario A</td>
<td>A favor</td>
</tr>
<tr>
<td>Sen.</td>
<td>José Ejemplo</td>
<td>Grupo Parlamentario B</td>
<td>En contra</td>
</tr>
<tr>
<td>Dip.</td>
<td>Registro no senatorial</td>
<td>Grupo Parlamentario C</td>
<td>Abstención</td>
</tr>Extracción bajo fricción: Scrapy y WAF Incapsula
La extracción ocurre bajo fricción.
El portal está protegido por WAF Incapsula, una capa que puede introducir bloqueos, respuestas variables, sesiones inestables o accesos incompletos. Esa fricción obliga a tratar cada respuesta como evidencia, no como verdad final.
Una página accesible no equivale automáticamente a una página correcta. Un fragmento recibido no garantiza que la fuente esté completa. Una ausencia puede significar que no hay datos, que el HTML no los expone, que la respuesta fue parcial o que el metadato no es auditable desde esa ruta.
La extracción produce una base operacional. La validación posterior decide qué parte de esa base puede sostenerse como dataset senatorial.
Persistencia: de fragmentos a SQLite
El paso siguiente convierte fragmentos dispersos en una base SQLite consultable.
Ahí la información deja de depender de la navegación institucional y pasa a organizarse como entidades relacionadas: votaciones, votos nominales, senadores identificados en votos, perfiles disponibles, partidos, sentidos del voto y anomalías detectables.
El resultado confirmado contiene:
| Métrica | Valor confirmado |
|---|---|
| Votaciones | 4,993 |
| Votos nominales senatoriales | 454,094 |
| IDs de senador presentes en votos | 737 |
| Perfiles disponibles | 700 |
| IDs en votos sin perfil asociado | 37 |
| Votaciones sin votos | 7 |
| Votos vacíos | 14 |
| Partidos vacíos | 88 |
La diferencia entre 737 IDs presentes en votos y 700 perfiles disponibles no se esconde. Es parte del estado real del dataset: hay 37 IDs de senador que aparecen en votos, pero no tienen perfil asociado en la capa disponible.
Validación read-only
La validación no modifica la base.
Su función es leer, contar, cruzar y señalar. Esa decisión importa: cuando una fuente institucional es incompleta o irregular, corregir silenciosamente puede destruir evidencia sobre la fuente original.
El validador read-only verifica consistencia interna sin reescribir los datos. Marca anomalías, confirma conteos y separa problemas reales de advertencias aceptables.
Los hallazgos confirmados incluyen siete votaciones sin votos:
408, 621, 801, 848, 3697, 3698, 3848También registra 14 votos vacíos y 88 partidos vacíos.
Estos casos no invalidan automáticamente el dataset completo. Funcionan como marcas de frontera: señalan dónde la cobertura baja, dónde la fuente no entrega todo o dónde la extracción no debe inventar información.
Auditoría: advertencias no son fallas automáticas
La auditoría separa errores críticos de advertencias aceptadas.
Un warning no equivale automáticamente a una falla. Puede indicar una ausencia real en la fuente, un perfil no disponible, un metadato incompleto, una pieza HTML no auditable o una inconsistencia heredada del portal.
La diferencia es central: el objetivo no es fabricar una base perfecta, sino declarar con precisión qué está validado, qué está incompleto y qué debe leerse con cautela.
| Nivel | Lectura operativa |
|---|---|
| Validado | Conteo, cruce o regla confirmada por la auditoría read-only. |
| Advertencia aceptada | Anomalía conocida que conserva contexto y no invalida el conjunto completo. |
| Requiere revisión | Caso que necesita inspección adicional antes de usarse como evidencia fuerte. |
La tesis operativa es simple: una fuente institucional hostil se vuelve dataset cuando cada transformación deja rastro, cada vacío queda contado y cada advertencia conserva su contexto.
El contrato senatorial: Sen. no es Dip.
El dataset no intenta copiar literalmente la fuente institucional. La traduce a un contrato senatorial verificable.
La regla central es esta: votos_nominales contiene el subconjunto nominal de senadores, identificado por registros Sen.. No es una réplica del AJAX bruto cuando la respuesta institucional mezcla otros cargos.
Esto importa porque algunas respuestas pueden incluir registros Dip.. Esos registros pueden existir en el bruto institucional, pero no pertenecen al contrato senatorial de este dataset.
Por tanto:
| Entrada institucional | Regla | Resultado en votos_nominales |
|---|---|---|
Registro Sen. | Pertenece al subconjunto senatorial | Se conserva |
Registro Dip. | No pertenece al contrato senatorial | Se excluye |
| Respuesta mixta | Se filtra por pertenencia senatorial | No se replica completa |
Los casos auditados 891, 3450 y 4890 fijan esta frontera con ejemplos concretos. La validez del dataset no depende de asumir que toda respuesta AJAX es senatorial, sino de aplicar una regla explícita de pertenencia.
Frontera Popolo
Popolo aparece aquí como frontera externa.
camara-senadores-mex valida información senatorial extraída del portal institucional. Esa información puede dialogar después con una representación Popolo, pero este documento no entra en los internals de popolo-senadores-mex.
La separación evita mezclar dos responsabilidades:
- aquí: reconstruir y validar datos senatoriales desde una fuente institucional hostil;
- afuera: representar personas, cargos o relaciones bajo una estructura Popolo.
Popolo funciona como caja externa de salida o contraste. No es la prueba primaria de verdad del scraping senatorial.
Garantías y límites
Garantías
- El dataset contiene 4,993 votaciones y 454,094 votos nominales senatoriales confirmados.
votos_nominalesrepresenta el subconjunto nominal de senadores (Sen.).- Las respuestas AJAX mixtas no se replican completas si incluyen registros
Dip.. - Los casos 891, 3450 y 4890 fueron usados como puntos de auditoría para fijar la frontera
Sen./Dip.. - La validación read-only cuenta anomalías sin modificar silenciosamente la base.
- Los vacíos conocidos quedan visibles: 37 IDs sin perfil, 7 votaciones sin votos, 14 votos vacíos y 88 partidos vacíos.
Límites
- La fuente institucional está protegida por WAF Incapsula, lo que introduce fricción y variabilidad de acceso.
- El HTML no siempre es suficiente como evidencia final.
- Metadata y perfiles pueden estar incompletos o no ser siempre auditables.
- Un warning aceptado no equivale automáticamente a una falla.
- El dataset no promete completitud absoluta de toda la publicación institucional.
- Popolo queda fuera de esta validación; se trata como frontera externa.