[Grey-Walter] (pr:topact) resumen 1

Pablo pablo at lechuza.rec.usal.es
Fri Dec 5 18:17:56 CET 2003


Hola, llevaba un tiempo desconectado de la lista y ahora que la he 
retomado he decidido hacer un resumen para aclararnos (yo por lo 
menos) como está todo.

Descripción del Proyecto Topact
-------------------------------------

El proyecto topact surge como una iniciativa para desarrollar la 
topología (análisis estructural y característico) de una red, en 
concreto la red activista estatal y, simultáneamente, la generación 
de material propio sobre las diferentes líneas de investigación que 
se lleven a cabo para la finalización del proyecto.

Para llevar acabo estos objetivos se dividirá el proyecto en una 
serie de módulos (actividades) que se pondrán en marcha para cada una 
de las fases del proyecto.

Módulos
----------

..::Debates::..
Hasta el momento de los tres temas básicos (qué mapear, qué 
consecuencias traen los mapeos y qué obtenemos con los mapeos) que se 
consideraban debatir se han tratado dos:

	o Qué mapear? De momento sólo se tratarán las páginas webs de los
	grupos albergados en sinDominio, excluyendo las listas de correo y
	las sindicaciones.
	o Consecuencias, ¿se deben hacer públicos los resultados?: A pesar
	de que un trabajo de este tipo podría ofrecer abundante información
	sobre la red estudiada (vulnerabilidades, fallos, puntos débiles,
	etc.) y esta información podría utilizarse contra la propia red
	estudiada, esta información también presenta la posibilidad de
	arreglar esos puntos débiles que posee la red, además de que la
	transparencia es una de las piezas clave para poder llevar a cabo
	alguna acción y añade una capacidad de invulnerabilidad.

Resta saber qué información nos aportaría un estudio como éste y 
hasta que punto se ciñe a la realidad. En mi opinión nos aporta la 
posibilidad de ver cómo se organizan estas redes, cuáles son sus 
centros neurálgicos, así como sus puntos fuertes/débiles, ver cómo 
evolucionan, si se forman nuevas redes en su interior, redes 
parelelas y similares, si absorbe o se fusiona con otras redes (por 
ejemplo hace unos años el activismo político de izquierdas no estaba 
muy relacionado con el software libre, sin embargo hoy en día cada 
vez van más unidos nop?).
Para que este estudio se ajuste a la realidad hay que hacerlo de 
forma continua, no dejar nunca de sondear la red estudiada para ver 
cómo evoluciona.


..::Reto::..
El reto consiste en un problema que se resolverá entre toda la lista
El diseño del algoritmo sería un reto?

.:Lecturas:.
Son lecturas que se harán y comentarán en la lista de forma que se 
aprendan nuevos campos y se generen materiales para estudios 
posteriores o para la publicación

..::Cursos, Material::..
Como forma de publicación del conocimiento generado con las lecturas, 
los trabajos, estudios particulares, partes del proyecto, etc.

..::Programación::..
Aplicación práctica de todo lo estudiado y debatido en los módulos 
anteriores.

Fases y desarrollo
---------------------

.:Exploración:.
Ahora mismo ya hemos fijado los límites del mapeo (red activista 
establecida en sinDominio y limitada a las páginas web), hemos 
encontrado el estudio sobre la Blogosfera (que convendría estudiar 
con un poco de profundidad) y un par de textos que pueden estar 
interesantes para pasar al módulo de lecturas.

El algoritmo de mapeo que se me ha ocurrido lo expongo al final de 
esta parte.

.:Aprendizaje:.
Incluye la lectura de los textos encontrados y las primeras de 
pruebas de uso o programación de los programas requeridos.

Posteriormente iríamos pasando a las demás fases: aproximación, 
topométrica-topográfica, topológica y publicación.

-- Adicionalmente queda pendiente a) fijar un calendario, b) 
coordinación de módulos y c)diseño definitivo.


Algoritmo de mapeo:

Según hemos visto nuestro proyecto plantea crear un sistema que 
mediante el análisis de diversas fuentes (páginas webs, logs, listas 
de correo, sindicaciones, etc.) construya una base de datos que 
posteriormente sea analizada y representada para extraer unas 
conclusiones.

He pensado en dividir tal sistema en 3 partes (o interfaces o capas o 
como queráis llamarlo), que se corresponderían con la topometría, la 
topografía y la topología/cartografía:

1. Interfaz de recogida y absorción del web. Se encargaría de ir 
filtrando y analizando el medio oportuno (logs, web, listas de 
correo, etc.) e ir generando información estándar, similar 
independientemente de que el medio sea una web, un log... y 
procesable por la interfaz 3. Esta información se almacenaría 
mediante la interfaz 2.
Esto sería un crawler que recorriese la web de sinDominio, detecte
a) qué tipos de datos recibe (txt, html o similares, png, pdf...) y 
si los puede analizar o no,
b) el idioma en que están tales datos y en función de éste si se 
desechan o se archivarán indicando que están en el idioma que sea.
Tratándose de sinDominio me temo que estará casi todo en castellano, 
pero por escalabilidad será más adecuado dar soporte a distintos 
idiomas, aunque sea en versiones posteriores.
c) de qué va la página recibida, esto es, sacar las keywords de la 
página. Sólo si se van a analizar los artículos, por ejemplo para 
determinar si se repiten o no en otras páginas.
y tras la detección se dedique a la extracción de los links de la 
página (lo que incluye "completarlos" y verificarlos) para almacenar 
en la interfaz 2 la dirección de la página y la dirección de las 
páginas enlazadas, así como otra info. (idioma, tamaño, keywords, 
última acutalización del registro, primera actualización, etc.)
Este crawler se ejecutaría en ordenadores "normales" (los que tenemos 
en casa en el trabajo, los "nuestros")

2. Interfaz de almacenamiento. Recibiría datos de la interfaz 1 y los 
almacenaría para que en un momento dado la interfaz 3 pueda 
analizarlos.
Bueno, esto trataría de una base de datos, por nombrar una MySQL que 
es más o menos gpl y muy potente.
Se ejecutaría en un servidor, p.ej. de sinDominio, y recibiría la 
información de los diferentes crawlers instalados en nuestros 
ordenadores que han ido explorando el web.
Hay que garantizar que los datos que recibe de los crawlers son 
verdaderos, para esto podemos:
a) fiarnos sin más (si suponemos que nadie tiene la intención de 
alterar los datos),
b) hacer que la conexión se haga encriptada (un túnel SSH p.ej.) para 
garantizar que nadie altera los datos por el camino (sin embargo nos 
estamos fiando de que el cliente sea de confianza ) o
c) repartir claves públicas (una distinta para cada usuario, que 
tendrían que registrarse antes de poder trabajar), además usar un 
túnel SSH y además guardar en la base de datos (BBDD) quién introduce 
qué registro y cuándo (para poder eliminar los registros trucados de 
un posible saboteador del análisis). Esta opción es la más segura 
pero la que más dificulta la participación de la gente (es cerrada) y 
la más compleja de programar (esto es más tiempo, más fallos, más 
quebraderos de cabeza, más limitaciones, etc.)
Habría que definir qué formato tendría cada entrada en la BD y cómo 
se organizaría ésta, ¿alguien sabe de bases de datos?


3. Interfaz de análisis. Analiza los datos que saca de la interfaz 2 
y que han sido estandarizados por la interfaz 1 antes de incluirlos 
en la 2. Muestra los resultados, las conclusiones, el zumo que sale 
tras analizar todo lo que ha recogido la interfaz 1 y se ha 
introducido en la 2.
Una retaíla de programas (que no tienen porque ejecutarse en el 
servidor) que vaya leyendo los registros de la base de datos (se 
conecta al servidor y lee) y sacando gaficos, dibujitos, 
distribuciones estadísticas, conclusiones, etc.
Sabéis algo de data mining? el datawarehouse tiene algo que ver en 
esto?
aquí quizá se puedan aplicar redes neuronales que saquen 
conclusiones, sistemas expertos?...
Lo básico sería un programa que muestre los datos de la BD para 
comprobar si todo va bien, luego ya se mejorarían



Consideraciones Finales:

Propongo que:
- discutamos este planteamiento en la lista. Si os parece damos de 
plazo hasta el lunes 17 para que el algoritmo ya esté perfectamente 
planteado y definido (dentro de lo posible). Tb. se definirán el 
formato de las entradas de la base de datos, la forma de conexiones y 
demás cuestiones comunes a las 3 interfaces. Podemos ve el 
plantemiento del estudio de la blogosfera
- si os parece bien vamos haciendo grupos de desarrollo dentro del 
módulo de Programación de forma que ya se vayan programando las 
diferentes interfaces en cuanto los puntos comunes estén bien 
definidos. Desde luego hay que tratar de reutilizar código al máximo 
(estoy presuponiendo qeu vamos a programar casi todo en vez de 
utilizar programas ya existentes) para ahorrar tiempo. La interfaz 2 
conociendo MySQL ya está prácticamente hecha ya que mysql es muy 
potente (aunque hay que vigilar la seguridad), si conocéis otra BD 
comentad.
- vamos desarrollando unas lecturas,unos retos, debates, etc.
- fijemos un calendario para todas las actividades

de programar, en qué lenguaje? para qué sistemas? ojo! yo he escrito 
esto con C+linux en la cabeza.

Para la programación hay que utilizar CVS o un sistema similar, no sé 
si sindominio tiene un servidor CVS, hispalinux sí. Es necesario para 
programar adecuadamente entre varias personas (y tb. que esas 
personas tengan su reloj en hora, para lo cuál no está de más un 
servidor ntp o parecido)


Para tratar todos los temas que tenemos que tratar hay que utilizar 
por fuerza el algoritmo de formato de sujeto del mensaje y hay que 
procurar que los mensajes sean muy concretos (no un mensaje que 
pinche en todos lados como éste sino muchos mensajes que cada uno 
toque en su parte)

creo que ya está todo, si habéis llegado hasta aquí premio!: botella 
de lejía para el caballero (hay alguna tía en la lista o estamos como 
siempre??)




More information about the Grey-Walter mailing list