Pyticli: satisfactibilidad deproposiciones en logica temporal deintervalos por medio de lenguajes de

consulta sobre grafos.

Javier de la Rosa, versae@gmail.com

Master en Logica, Computacion e Inteligencia ArtificialUniversidad de Sevilla

26 de agosto de 2011

Resumen

El presente documento es el trabajo final del Master en Logica,Computabilidad e Inteligencia Artificial impartido por la Universidadde Sevilla en el curso academico 2010–2011.

Presenta el lenguaje Pyticli, un sub-lenguaje del lenguaje de pro-gramacion Python, construido para traducir proposiciones de logicatemporal de intervalos a consultas en lenguajes disenados para ata-car bases de datos en grafo. Para ello hace uso del generador internode arboles de sintaxis abstrata de Python, a lo que posteriormenteaplica un mecanismo de reduccion para construir una representacionabstracta de la consulta que pueda ser convertida a cualquier lenguajede consulta para bases de datos en grafo.

Keywords Bases de Datos en Grafo, Logica Temporal, Lenguajes de Con-sulta.

Director Andres Cordon Franco, acordon@us.es.

1

((Ay, Piticli, bonico, Piticli, ay, Piticli)) 1.

Agradecimientos.

Este trabajo no serıa posible sin la paciencia y compresion del profesoradodel Master en Logica, Computacion e Inteligencia Artificial, que han mostra-do su caracter mas humano permitiendome no solo ser evaluado a distancia,sino ademas componer un jurado para el presente documento aun en periodovacacional. En especial quisiera dar las gracias a Andres Cordon, directordel trabajo, por todos sus comentarios y correcciones in extremis ; a JoaquınBorrego por implicarse en que este documento sea posible y ademas este en-tregado a tiempo; y a Fernando Sancho que siempre ha tenido un hueco paracalmarme y llevarme por el buen camino, y sin el que mi futuro y mi presenteserıan bien distintos.

No quiero tampoco olvidar la labor de Juan Luis Suarez, profesor de laUniversity of Western-Ontario, quien en mas de una ocasion me ha permitidousar el tiempo y los recursos del laboratorio que dirige –y para el que trabajo–para mi uso personal en la elaboracion de este proyecto.

Por ultimo quisiera dar las gracias a todos los que me han apoyado desdeEspana, Reino Unido y Canada, quienes parecen tener mas fe en mı que yomismo. Y por supuesto a mi pareja, Esperanza Ruiz-Pena, sin cuyo apoyo yconfianza diarias no podrıa haber aguantado hasta el final. Gracias.

Como se suele decir, menos da una piedra.

1Enjuto Mojamuto – La Mascota: http://youtu.be/PZORAvBz4k0

2

INDICE INDICE

Indice

1. Introduccion. 61.1. Model Checking. . . . . . . . . . . . . . . . . . . . . . . . . . 71.2. Estructura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Logica Modal. 92.1. Logica Temporal. . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Logica Temporal de Intervalos. 113.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. Satisfactibilidad. . . . . . . . . . . . . . . . . . . . . . . . . . 123.4. Interpretacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Programacion Logica. 164.1. Programacion en logica temporal. . . . . . . . . . . . . . . . . 18

4.1.1. Chronolog. . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.2. Templog. . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.3. Temporal Prolog de Gabbay. . . . . . . . . . . . . . . . 194.1.4. Temporal Prolog de Sakuragawa. . . . . . . . . . . . . 20

4.2. Programacion en logica de intervalos. . . . . . . . . . . . . . . 204.2.1. Tempura. . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2. Tokio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3. Programacion en logica reificada. . . . . . . . . . . . . . . . . 224.3.1. Temporal Prolog de Hrycej. . . . . . . . . . . . . . . . 224.3.2. Starlog. . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5. Representacion del conocimiento. 245.1. Sistemas de transicion etiquetados. . . . . . . . . . . . . . . . 245.2. Estructuras de Kripke. . . . . . . . . . . . . . . . . . . . . . . 255.3. Consideraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6. Bases de Datos en Grafo. 286.1. Bases de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1.1. DEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.2. FlockDB. . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.3. HyperGraphDB. . . . . . . . . . . . . . . . . . . . . . 30

3

INDICE INDICE

6.1.4. InfoGrid. . . . . . . . . . . . . . . . . . . . . . . . . . . 316.1.5. InfiniteGraph. . . . . . . . . . . . . . . . . . . . . . . . 326.1.6. Neo4j. . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1.7. OrientDB. . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2. Lenguajes de consulta. . . . . . . . . . . . . . . . . . . . . . . 346.2.1. GQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.2. GraphLog. . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.3. Gremlin. . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.4. PQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.5. SPARQL. . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.6. UnQL/UnCAL. . . . . . . . . . . . . . . . . . . . . . . 36

7. Logica temporal de intervalos y consulta de grafos. 377.1. Estructuras de Kripke sobre bases de datos grafo. . . . . . . . 377.2. Logica temporal sobre lenguaje de consultas para grafos. . . . 38

7.2.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . 387.2.2. Satisfactibilidad. . . . . . . . . . . . . . . . . . . . . . 397.2.3. Interpretacion. . . . . . . . . . . . . . . . . . . . . . . 41

8. Lenguaje Pyticli. 438.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.2. Limitaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 458.3. Algoritmo de conversion. . . . . . . . . . . . . . . . . . . . . . 468.4. Aplicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.4.1. Operadores basicos. . . . . . . . . . . . . . . . . . . . . 518.4.2. Operadores compuestos. . . . . . . . . . . . . . . . . . 52

8.5. Mejoras al lenguaje. . . . . . . . . . . . . . . . . . . . . . . . . 528.5.1. Operadores ¬ y ∨. . . . . . . . . . . . . . . . . . . . . 538.5.2. Operadores temporales. . . . . . . . . . . . . . . . . . . 538.5.3. Lenguajes de salida. . . . . . . . . . . . . . . . . . . . 53

8.6. Consola interactiva. . . . . . . . . . . . . . . . . . . . . . . . . 55

9. Conclusiones y trabajo futuro. 58

10.Bibliografıa. 59

4

INDICE DE FIGURAS LIST OF ALGORITHMS

Indice de figuras

1. Grafo de estados con varios caminos posibles. . . . . . . . . . 402. Grafo de estados simple. . . . . . . . . . . . . . . . . . . . . . 40

List of Algorithms

1. Algoritmo general de conversion: Pyticli . . . . . . . . . . . 472. Algoritmo de procesado del AST: ProcessTree . . . . . . . . 483. Algoritmo de reduccion de pila: StackReduce . . . . . . . . . 50

5

1 INTRODUCCION.

1. Introduccion.

Este trabajo presenta las analogıas entre la logica modal proposicionaltemporal (en adelante logica temporal) y el dominio de la teorıa de grafos.

Los actuales lenguajes temporales, basados en el correpondiente sustratoteorico, estan ideados para generar estructuras y conjuntos de estados quesatisfagan proposiciones dadas, de manera que se pueda definir y caracterizarun determinado sistema (formalmente, modelo) a partir del comportamien-to esperado de este a lo largo del tiempo. Esto es especialmente util en ladefinicion de modelos concurrentes. Recientemente, la Association for Com-puting Machinery (ACM) concedio el Premio Turing a los creadores de unmecanismo automatico de verificacion de estos modelos2, tecnica que recibeel nombre de model checking.

La aproximacion que aquı se presenta esta a camino entre el model checkingy los lenguajes temporales. La finalidad ultima de este trabajo es proporcio-nar un marco practico sobre el cual poder verificar proposiciones especıficasde un sistema segun su comportamiento. Para ello suponemos que cada vezque el sistema cambia de un estado a otro, una traza conteniendo los valoresde cada variable es almacenada en una base de datos en grafo, de manera quese establezca una arista dirigida entre cada dos estados si desde un estado σise ha pasado a otro σj. El utilizar bases de datos en grafo para almacenaresta informacion es crucial ya que de esta manera se proporciona no solo unmetodo de almacenamiento eficaz, robusto, masivo y colaborativo, sino unmecanismo para realizar consultas sobre los datos a traves de los lenguajesnativos que implementan. Proponemos, en este sentido, un lenguaje capaz detraducir proposiciones de logica temporal a consultas sobre bases de datos engrafo, eliminando la complejidad inherente de la tecnica de model checking.

2Researchers Created Model Checking Technique for Hardware and Software Designers:http://www.acm.org/press-room/news-releases/turing-award-07/

6

1.1 Model Checking. 1 INTRODUCCION.

1.1. Model Checking.

Si definimos el proceso mediante el cual, dado un sistema de estados, es ne-cesario averiguar si un cierto conjunto de proposiciones se verifica, tendrıamoslo que se conoce como model checking [20]. Esta tecnica se emplea tanto ensistemas hardware como software, y ha demostrado ser especialmente util encomparacion con otras como la simulacion o el razonamiento, en sistemasparalelos y concurrentes [19].

La potencia de este metodo radica en que utiliza una representacion simboli-ca del espacio de estados, por lo que no debe enfrentarse a limitaciones deespacio fısico de almacenamiento. A traves del µ-Calculo y una logica tem-poral especıfica (CTL) es capaz de manipular formulas y relaciones y decidirsobre la satisfactibilidad de formulas expresdas en logica temporal lineal, evi-tando ası el problema conocido como explosion de estados –se conoce comoexplosion de estados al incremento exponencial de estados que se da al inten-tar verificar un sistema concurrente. Este problema relego en un principio laverificacion automatica a sistemas pequenos y fue el origen del model chec-king ; pero con la aparicion de los nuevos sistemas de bases de datos en grafo,capaces de escalar eficientemente, la cantidad maxima de estados posibles enun sistema se incrementa de nuevo, pudiendo ahora esta tecnica ser aplicadaen maquinas de caracterısticas sencillas y asequibles.

A posteriori, el algoritmo de conversion de proposiciones de logica temporala consultas sobre grafos ha resultado tener ciertas similitudes al empleado enmodel checking para µ-Calculo, incluso sin haber sido inspirado en el.

1.2. Estructura.

Tras una primera presentacion de las logicas modales y un posterior anali-sis y definicion de las logicas temporales, se muestran algunas de las distintasimplementaciones que se han ido desarrollando a lo largo del tiempo, pasan-do desde las basadas exclusivamente en Prolog o Lisp [7, 8] hasta lenguajescompletos con sintaxis propia desarrollados en C [60].

La siguiente seccion hace una breve introduccion a las bases de conocimien-to entendidas en el marco de la programacion lineal y los sistemas deductivos

7

1.2 Estructura. 1 INTRODUCCION.

e inductivos. El estudio se centra especıficamente en los Sistemas de Tran-sicion Etiquetados, usados en la logica temporal basada en acciones, y lasestructuras de Kripke, que sustentan la logica temporal basada en estados.Ambas construcciones son, como veremos, formas particulares de grafos.

Un apartado dedicado a la definicion de las bases de datos basadas engrafo, que vienen a integrar el grupo de las recien nombradas NoSQL (queconviene no confundir con el gestor de bases de datos de identico nombre [51])tambien es presentado. Tras numerar algunas de las mas conocidas de estasbases de datos, se introducen a continuacion los lenguajes sobre los que seconstruyen las consultas y que resultan indispensables en cualquier base dedatos.

Por ultimo discutiremos como esta aproximacion entre ambos mundos pue-de repercutir positivamente de cara a decidir sobre las proposiciones tempora-les cuyos atomos forman parte de un grafo masivo almacenado eficientementeen disco. Los ultimos apartados se dejan para las conclusiones y el posteriortrabajo futuro.

8

2 LOGICA MODAL.

2. Logica Modal.

Las logicas modales forman parte de las logicas formales y amplıan sudominio para incluir el estudio de propiedades dependientes del contexto –modalidad– tales como necesidad y posibilidad [10, 11]. Para ello hacen usode dos nuevos sımbolos que anaden a los ya existentes en el vocabulario de lalogica proposicional a la que extienden, estos son � para denotar necesidad,es necesario que; y 3 para posibilidad, es posible que. Quedando ademasdefinidos cada uno en funcion del otro como se muestra en (1 , 2).

3p = ¬�¬q (1)

�p = ¬3¬q (2)

Existe pues una clara analogıa con los cuantificadores en la logica deprimer orden, donde se tiene (3, 4).

∃xφ(x) = ¬∀x¬φ(x) (3)

∀xφ(x) = ¬∃x¬φ(x) (4)

La regla de inferencia mas habitual en la logica modal es la necesita-cion (5), y junto al modus ponens de la logica proposicional permiten definirdistintos tipos de sistema.

` φ` �φ

(5)

Cada sistema esta basado en unos axiomas y dependiendo de cuales ycuantos utilice sera posible demostrar un mayor o menor numero de teo-remas. Ası, partiendo del axioma mas basico, denominado K (6) en honora Samuel Kripke [45], podemos anadir distintos axiomas obteniendo cadavez un sistema distinto sobre el que aplicar una interpretacion. Los axiomasde K tambien incluyen todas las instancias de las tautologıas de la logicaproposicional.

�(φ→ ψ)→ (�φ→ �ψ) (6)

3φ↔ ¬�¬φ (7)

De manera que las reglas para una K-prueba son:

9

2.1 Logica Temporal. 2 LOGICA MODAL.

Modus ponens. Dados φ y φ =⇒ ψ, se tiene ψ.

Sustitucion (uniforme). Dado φ se tiene θ, donde θ se obtiene a partirde φ reemplazando uniformemente los atomos de la proposicion en φpor formulas arbitrarias.

Generalizacion. Dado φ, se tiene �φ.

Si definimos como estructura relacional la tupla 〈W,R1, . . . , Rk〉 tal que Wes un conjunto no vacıo y cada Ri es una relacion sobre W , podemos definiruna interpretacion o modelo como la tupla M = 〈F, v〉, donde:

F es un marco definido por la tupla 〈W,R〉 y donde:

• W es un conjunto no vacıo de elementos que reciben el nombre demundos posibles.

• R es una relacion entre los mundos posibles denominada relacionde accesibilidad. La relacion de accesibilidad puede ser reflexiva,transitiva, euclıdea y/o simetrica, lo que permite obtener los dis-tintos tipos de sistemas.

v es un asignacion en un marco F = 〈W,R〉 y viene dada por la fun-cion que asocia a cada sımbolo proposicional el subconjunto de mundosdonde es verdadera.

2.1. Logica Temporal.

La logica temporal [14, 72] puede verse como una instancia de la logicamodal en la que el conjunto de mundos posibles representa una coleccionde instantes o momentos en el tiempo [64]. Anade dos nuevos operadoresexistenciales a la logica modal proposicional, cuyas lecturas son [29]:

〈P 〉φ, φ se satisface en algun momento del pasado (Past).

〈F 〉φ, φ se satisface en algun momento del futuro (Futuro).

Tambien son habituales los correspondientes duales, que tienen caracter uni-versal:

[H]φ = ¬〈P 〉¬φ, φ siempre ha sido (Has been) satisfecha en el pasado.Es decir, no existe un momento en el pasado en que φ no se satisfaga.

10

3 LOGICA TEMPORAL DE INTERVALOS.

[G]φ = ¬〈F 〉¬φ, φ siempre va a ser (Going to be) satisfecha en elfuturo. Es decir, no existe un momento en el futuro en que φ no se vayaa satisfacer.

A partir de estos operadores –que suelen escribirse simplemente como P ,F , H y G– se pueden construir sistemas mas o menos especıficos segun lasrestricciones que se incluyan sobre las relaciones. Ası, un marco adecuadopara la logica temporal basica podrıa incluir dos relaciones binarias [29], RP

y RF , que facilitasen las definiciones de transitividad y reciprocidad (logicamodal normal) Pφ→ GPφ para expresar que ((lo que sea que haya ocurridosiempre ha ocurrido)) [10]; una nocion de tiempo denso estableciendo conFφ→ FFφ que entre cualesquiera dos instantes siempre hay un tercero [10];o la conocida como formula de McKinsey [56], GFφ → FGφ, algo ası comoun reflejo de la nocion termodinamica de la distribucion de la informacion.

3. Logica Temporal de Intervalos.

La Logica Temporal de Intervalos o ITL [58, 37, 59] fue propuesta porprimera vez por Ben Moszkowski. A lo largo de esta seccion seguiremos lasdirectrices y nomenclaturas usadas por Moszkowski en [60], donde propone eluso de dos nuevos sımbolos logicos, # (siguiente) y � (siempre), y a los queanade los operadores = (igualdad) y ∧ (conjuncion). Sin embargo, aunqueel resto de operadores logicos puede deducirse a partir de los anteriores,nosotros daremos tambien por validas todas las conectivas propias de la logicaproposicional.

3.1. Sintaxis.

Para construir expresiones usaremos lo siguiente:

Variables individuales: A, B, . . .

Funciones: f(e1, . . . , ek), donde k ≥ 0 y cada ei es una expresion. Su-ponemos predefinidas funciones aritmeticas basicas como + o mod,ademas de las constantes 0 y 1.

Operador siguiente: #e, donde e es una expresion.

Por su parte, las formulas se construiran como sigue:

11

3.2 Modelos. 3 LOGICA TEMPORAL DE INTERVALOS.

Predicados: p(e1, . . . , ek), donde k ≥ 0 y cada ei es una expresion. Eneste caso tambien suponemos definidas relaciones como ≤.

Igualdad: e1 = e2, donde cada ei es una expresion.

Conectivas logicas: ¬w1 y w2 ∧ w3, donde cada wi es una formula.

Operador ((siguiente)) (next): #w, donde w es una formula.

Operador ((siempre)) (always): �w, donde w es una formula.

3.2. Modelos.

En ITL, un modelo es una tripleta 〈D,Σ,M〉 donde D es el dominio delos datos, Σ el conjunto de estados, y M una interpretacion que dota designificado a cada sımbolo de predicado y funcion. Un estado es una funcionque mapea variables a valores de un dominio, ası, podemos tener un estados de D en el que la variable A tenga el valor 5, lo que denotaremos porsJAK = 5. Cada sımbolo de funcion f tiene una interpretacion MJfK quemapea k elementos en D a un solo valor (8).

MJfK ∈ (Dk → D) (8)

Para el caso de las proposiciones, que deben ser evaluadas como ciertas ofalsas, usaremos true y false (9).

MJfK ∈ (Dk → {true, false}) (9)

Dado Σ, definimos I = Σ+ como el conjunto de todas las secuencias finitas yno vacıas de estados. La longitud de un intervalo σ ∈ I vendra dada por |σ|y se correspondera con el numero de estados en el intervalo menos uno, demanera que cada intervalo estara compuestos de al menos un estado σi (10).

σ = 〈σ0, σ1, . . . , σ|σ|〉 (10)

3.3. Satisfactibilidad.

Decimos que una formula w es satisfecha en un intervalo σ, o que elintervalo σ satisface la formula w si y solo si el significado de w en σ es iguala true (11), lo que puede denotarse de forma abreviada (12).

MσJwK = true (11)

12

3.4 Interpretacion. 3 LOGICA TEMPORAL DE INTERVALOS.

σ |= w (12)

Si todos los intervalos satisfacen w, entonces decimos que w es valida (13).

|= w (13)

3.4. Interpretacion.

Para dar significado a expresiones y formulas sobre intervalos, definimosMσJeK como el valor en D de la expresion e en el intervalo σ. Analogamente,MσJwK sera el resultado logico (true o false) de la formula w en σ. Puedea veces encontrarse esta notacion de forma abreviada eliminando la notacionde modelo (14)

MσJeK ≡ JeKσ (14)

MσJwK ≡ JwKσ (15)

El listado de definiciones es el que sigue:

MσJV K = σ0JV K, donde V es una variable. Es decir, el valor de unavariable en un intervalo es igual a su valor en el estado inicial delintervalo.

MσJf(e1, . . . , ek)K =MσJfK(MσJe1K, . . . ,MσJekK), de manera de quela interpretacion del sımbolo de funcion f se aplica a las interpretacio-nes de e1, . . . , ek.

MσJp(e1, . . . , ek)K = MσJpK(MσJe1K, . . . ,MσJekK) . De forma similara la definicion anterior.

MσJei = ejK = true↔MσJeiK =MσJejK

MσJ¬wK = true↔MσJwK = false

MσJwi ∧ wjK = true↔ (MσJeiK = true) ∧ (MσJejK = true)

MσJ#eK = M〈σ1,...,σ|σ|〉JeK, si se tiene que |σ| ≥ 1. El valor de #e sedeja sin especificar sobre intervalos de longitud 0.

MσJ#wK = true, en el caso en que |σ| ≥ 1 y ademasM〈σ1,...,σ|σ|〉JwK =true.

13

3.4 Interpretacion. 3 LOGICA TEMPORAL DE INTERVALOS.

MσJ�wK = true↔ ∀i ≤ |σ| :M〈σi,...,σ|σ|〉JwK = true.

A partir de aquı podemos derivar otros tantos operadores secundarios quese apoyen en las definiciones anteriores pero que faciliten un poco la creacionde proposiciones mas ricas.

MσJ3wK = true ↔ ∃i ≤ |σ| : M〈σi,...,σ|σ|〉JwK = true. Este es eloperador ((a veces)) (sometimes) y es el dual de always, ya que 3wpuede ser definido como ¬�¬w.

MσJlen(e)K = true ↔ MσJeK = |σ|. Conocido como el operador lon-gitud, permite comprobar si la longitud de un intervalo σ es igual a laexpresion e.

wi ∨ wj serıa equivalente a ¬(¬wi ∧ ¬wj)

wi ⊃ wj, la implicacion vendrıa dada por ¬wi ∨ wj

if b thenwi elsewj. La construccion del condicional se hace utilizandoel operador de implicacion, (b ⊃ wi) ∧ (¬b ⊃ wj).

wi ≡ wj se obtendrıa a partir de (wi ⊃ wj) ∧ (wj ⊃ wi)

empty ≡ ¬# true, es decir se tiene que empty es cierto si el intervaloσ no tiene estados (longitud 0): σ |= empty ↔ |σ| = 0.

more ≡ #true, o lo que es lo mismo, ya que se trata del opuesto aempty, σ |= more ≡ ¬empty.

ei gets ej ≡ �(more ⊃ [(#ei) = ej]), lo que vendrıa a ser lo mismo que∀k|σ| : σk+1JeiK = JejK. Es decir, se cumple en todos los estados que elsiguiente a ei es siempre ej. Podrıamos hacer una lectura aproximadainterpretando gets como ((llega a ser)), o ((se convierte en)).

stable e ≡ e gets e, para expresiones que no varıan con el paso del tiem-po.

halt w tendrıa una definicion equivalente a �(w ≡ empty), es decir,comprueba si w se evalua a false en todos los estados salvo el ultimo,donde deberıa ser cierta para que halt w = true.

ei ≈ ej, se conoce como igualdad temporal es cierta si y solo si �(ei =ej).

14

3.4 Interpretacion. 3 LOGICA TEMPORAL DE INTERVALOS.

w©w. Es el operador weak next cuya definicion viene dada por empty ∨#w. Se interpreta como la version debil del operador next en el sen-tido de que su valor tambien es true incluso cuando el intervalo tienelongitud 0.

finw, definido como �(empty ⊃ w), permite establecer condiciones asatisfacer en el ultima estado de un intervalo, independientemete de loque ocurra en el resto (version debil de halt).

ei → ej, conocido como asignacion temporal, es equivalente a decirque ∃a : [(a = ei) ∨ (fin(ej) = a)]. Su comportamtiento es, por tanto,verificar que el valor de ej en el estado final σ|σ| es el mismo que el deei en el estado inicial σ0. Podrıamos decir que es una forma de post-condicion que busca ser verificada si la relacion entre ei y ej se mantieneconstante entre los estados inicial y final.

skipw toma valor true en intervalos que tienen un unico estado (lon-gitud 1), por lo que puede expresarse como #empty.

Ademas de estos, otros operadores pueden ser definidos para facilitar la crea-cion de proposiciones expresadas en ITL, sin embargo no seran tenidos encuenta al estar basados en el operador chop de composicion secuencial que nodefiniremos formalmente. El operador chop puede ser usado para la defini-cion de nuevos operadores como las versiones inversas y acotadas de alwaysy sometimes, bucles e iteradores. En realidad a partir de chop se puedendefinir la mayor de parte de los operadores anteriores [39, 16, 58, 37].

De manera informal, podemos decir que chop permite particionar un inter-valo σ en dos subintervalos consecutivos que comparten un estado central. Lasintaxis habitual de chop suele ser el sımbolo ;, de manera que la expresionwi;wj es cierta si y solo si σ puede ser dividida en dos subintervalos, σi y σm,y wi se satisface en σl mientras que wj lo hace en σm. Este operador puedeextenderse por composicion, chop∗, para dividir σ en tantos subintervaloscomo sean precisos.

15

4 PROGRAMACION LOGICA.

4. Programacion Logica.

La semantica de los programas logicos fue desarrollada por Van Emden yKowalski [83] y, segun este ultimo, deben seguir una meta clara [44] respectoa los problemas que se pretenten resolver: ((Los programas logicos deberıanespecificar que va a ser computado; no como va a ser computado)). Es decir,mientras que en la programacion algorıtmica, la de lenguajes como C o Java,el control de la ejecucion va ligado a las instrucciones que resuelven el pro-blema, en la programacion declarativa en la que se incluye la programacionlogica solo se deberıan especificar el conocimiento y las asunciones que sobreun problema especıfico se tiene. Lo que se consigue por medio de las llama-das clausulas de Horn (clausulas con un literal positivo como maximo). Estasclausulas constituyen el sistema de axiomas que componen un programa logi-co, de manera que la prueba de satisfactibilidad del conjunto de clausulas secorresponda con la ejecucion del programa.

Denotamos como clausula de Horn la expresion A ← B1, . . . , Bn y, en suforma clausulada, ¬(B1 ∧ . . . ∧ Bn) ∨ A = ¬B1 ∨ . . . ∨ ¬Bn ∨ A, donde solohay, como maximo, un literal positivo A al que se denomina cabeza, mientrasque al resto de literales Bi se les denomina cuerpo. De esta manera podemoshacer una lectura aproximada diciendo que si cada Bi es una formula cierta,entonces A tambien lo es.

Las clausulas de Horn se clasifican en dos tipos:

Clausula objetivo u objetivo, aquella que no tiene literales positivos,¬B1 ∨ . . . ∨ ¬Bn, donde cada Bi es un sub-objetivo.

Clausula de programa, aquella que tiene al menos un literal negativo yun unico literal positivo. Si la clausula de programa solo consta de unliteral positivo A, se la llama clausula unitaria o hecho y se interpretaque A es una formula cierta para cada asignacion de cada variable. Alconjunto de hechos basicos se le suele denominar base de datos.

De esta manera podemos definir el programa logico como un conjunto depredicados, donde cada uno es a su vez un conjunto de clausulas de Horn quecomparten el literal en sus cabezas.

16

4 PROGRAMACION LOGICA.

La importancia de las clausulas de Horn y el motivo por el cual son el me-canismo sobre el que se construyeron lenguajes como Prolog, es la existenciadel metodo de resolucion lineal selectiva con clausulas definidas o SLD [43],un metodo adecuado y completo cuando se aplica en sistemas de clausulasde Horn. Basicamente el metodo consiste en aplicar derivaciones entre lasclausulas del programa P y la clausula objetivo G, de manera que una re-futacion de SLD sobre P ∪ G es una derivacion SLD finita de P ∪ G quetiene la clausula vacıa como ultimo objetivo en la derivacion. El metodo sedesarrolla por recursion mediante sustitucion por unificacion. En realidad sedefine implıcitamente un arbol de busqueda de las computaciones alternati-vas aplicando razonamiento con vuelta atras, de forma que la raız del arbolse asocia con la clausula meta incial y en el que cada nodo hoja es un nodosatisfactorio si su clausula objetivo asociada es la clausula vacıa. Si la clausu-la asociada a un nodo hoja no es vacıa pero su literal asociado ya no puedeunificarse con ninguna clausula de entrada, entonces se dice que el nodo esun fallo.

Si bien la programacion logica se aplica en un creciente numero de pro-blemas pertenecientes a muy diversos dominios, tambien adolece de ciertaslimitaciones. Es el caso de los problemas que requieren una nocion de cambiodinamico en el tiempo. A veces se ha intentado extender la programacionlogica con anotaciones, sistemas de predicados anadidos y otros mecanismos,y aunque estas son sin duda grandes contribuciones al mundo de la programa-cion, terminan por difuminar el caracter logico de los programas. La solucionno pasa por anadir caracterısticas no logicas a la programacion logica, sinoen desarrollar mejores y mas potentes herramientas como las logicas modaleso temporales.

En este sentido se presentan las logicas temporales, ya que representanla mejor manera de extender la programacion logica para modelar propie-dades dinamicas dependientes del tiempo como las usadas en razonamientotemporal o simulacion. Existen propuestas para extender la programacionlogica con logica temporal e incluso implementaciones operativas con algu-nas restricciones con respecto al desarrollo teorico. Una buena parte de estasimplementaciones de lenguajes temporales han sido construidas sobre Prolog,ya sea con modificationes en el algoritmo de unificacion interno SLD o conreglas extra para los operadores temporales.

17

4.1 Programacion en logica temporal. 4 PROGRAMACION LOGICA.

4.1. Programacion en logica temporal.

Las siguientes implementaciones estan basadas en los conceptos mas sim-ples de la logica temporal basica –lineal y de ramificacion– explicados en laseccion 2.1, extendiendolos segun las necesidades de cada lenguaje.

4.1.1. Chronolog.

Chronolog fue concebido por Wedge [86, 87] como propuesta sobre laprogramacion logica basada en clausulas de Horn antes de su materializaciondefinitiva como lenguaje [62, 63, 72]. Utiliza el conjunto de los naturales comola coleccion de momentos en el tiempo y consta de dos operadores temporales:

first , para referirse al momento inicial en el tiempo.

next , usado para el momento siguiente.

Esta concepcion implica una nocion de movimiento a traves del eje temporal.

4.1.2. Templog.

Originalmente propuesto por Abadi y Mann [1, 2], Templog utiliza un ejetemporal lineal y discreto con un futuro sin acotar basado en el conjunto delos numeros naturales. Templog tiene la misma sintaxis que Prolog exceptopor los tres operadores temporales que introduce:

#, el siguiente momento en el tiempo.

�, a partir de ahora.

3, alguna vez en el futuro.

Surgen ası algunos conceptos nuevos:

next-atom, atomos con un prefijo de operadores next. Se denota por#kA, donde A es un atomo y #k es una k -aplicacion del operador next,esto es, aplicar k veces el operador next para valores de k ≥ 0.

next-formula, formula compuesta de next-atoms.

clausula inicial , clausula de la forma B ← A1, . . . , An donde cada B ycada Ai son next-formulas.

18

4.1 Programacion en logica temporal. 4 PROGRAMACION LOGICA.

clausula permanente, analogamente, clausula de la formaB ⇐ A1, . . . , Andonde cada B y cada Ai son next-formulas. La diferencia con la clausulainicial es el caracter temporal, ya que la clausula permanente implicaal operador �.

Podemos definir ahora un programa en Templog como una conjuncion declausulas iniciales y permanentes, siendo el objetivo una conjuncion de next-formulas. Su procedimiento de resolucion, llamado TSLD , tiene un numerode reglas para tratar con los operadores temporales. De hecho, el poder ex-presivo de Templog es el mismo que el de un fragmento de sı mismo llamadoTL1 en el que el unico operador temporal es #.

Si bien puede demostrarse que tanto Chronolog como Templog tienen elmismo poder expresivo simplemente sustituyendo el operador # por next yaplicando first a todas las clausulas iniciales de Templog, el resultado notiene mayor trascendencia que el meramente teorico.

4.1.3. Temporal Prolog de Gabbay.

En [31] Gabbay propuso una extension de Prolog, a la que llamo conve-nientemente Temporal Prolog, que hacıa posible el uso de conectivas tempo-rales y modales en la programacion logica. Estas conectivas fueron en prin-cipio P , para expresar alguna vez en el pasado, F , para alguna vez en elfuturo, y � para la nocion de siempre. Aunque el lenguaje es muy expresivoe incluso permite implicaciones anidadas, � no puede usarse en las clausulasde programa. La sintaxis del lenguaje [32] es la que sigue:

programa, compuesto por un conjunto de clases.

clausula, que puede ser una clausula ordinaria o la clausula siempre.

clausula siempre, definida como �A donde A es una clausula ordinaria.

clausula ordinaria, que puede tener solo una cabeza o una clausula deltipo A→ H donde A es el cuerpo y H la cabeza.

cabeza, siendo esta una formula atomica o una construccion de la formaFA o PA, donde A es una conjuncion de clausulas ordinarias.

cuerpo, definido como una formula atomica, una conjuncion de cuerpos,o una formula del tipo FA o PA donde A es un cuerpo.

19

4.2 Programacion en logica de intervalos.4 PROGRAMACION LOGICA.

La admision de los operadores F y P en la cabeza de una clausula de progra-ma provocan, de acuerdo a Orgun y Wadge [63], que esta extension de Prologno cumpla con la semantica de modelo mınima. Aunque existen conjeturasque apuntan en la direccion contraria [64].

4.1.4. Temporal Prolog de Sakuragawa.

Otra implementacion llamada igualmente Temporal Prolog es la propues-ta por Sakuragawa [74, 1, 2]. La particularidad de esta extension respecto alas demas es que Sakuragawa considero en su lenguaje que todas las clausulasde pograma son causales, esto es, el significado de los predicados en el futurodepende de su significado en el pasado. Los operadores temporales relativosa tiempos pasados como • (momento previo en el tiempo) pueden darse enla cabeza de una clausula, lo que provoca que programas escritos en estaversion de Temporal Prolog no sean traducibles directamente a otros comoel de Gabbay, Templog o Chronolog.

4.2. Programacion en logica de intervalos.

Como se describe en la seccion 3, la logica temporal de intervalos es unaforma de logica temporal en la cual la semantica de las formulas se define pormedio de interpretaciones temporales y pares, es decir, pares de momentosen el tiempo que representan una duracion especıfica. Los dos lenguajes masrepresentativos de este tipo de logica son Tempura [60, 35] y Tokio [4], ambosconsiderados lenguajes para programacion temporal en un sentido amplio.

Este tipo de lenguajes, aunque pueden usar los mecanismos en su ejecu-cion, no esta basado en el paradigma habitual de la programacion logica deresolucion y unificacion. Incluso incluyen algunas caracterısticas heredadasde los lenguajes funcionales.

4.2.1. Tempura.

El lenguaje Tempura, propuesto por Moszkowski [60], ha llevado un desa-rrollo paralelo a la logica temporal de intervalos a la que se debe, aunque suimplementacion mantiene una nocion discreta del tiempo. No es de extranar,por tanto, que todos los operadores y sintaxis de la ITL tengan cabida enel lenguaje con una traduccion casi inmediata. Los operadores basicos de

20

4.2 Programacion en logica de intervalos.4 PROGRAMACION LOGICA.

Tempura son � (always) y 3 (sometimes), implementa el operador secuen-cial chop mediante la sintaxis ”;”, el operador # (next) y las conjunciones ∧de formulas y expresiones a traves de and. A partir de estos elementos, unprograma Tempura es un conjunto de formulas ejecutables, aunque tambienexiste un conjunto de operadores secundarios, definidos sobre los anteriores,para facilitar la tarea del programador y hacer el lenguaje mas asequible.Otra decision de diseno importante es la de eliminar la disyuncion ∨ y lanegacion ¬ en aras de la eficiencia.

Las ejecuciones de los programas escritos para Tempura consisten en pro-cesos de reduccion, debido a que en cada ejecucion el programa se reduceconforme a las operaciones en los intervalos de tiempo, y se repite el procesosucesivamente hasta que el subintervalo actual a evaluar solo consta de unestado, esto es, el intervalo no puede volver a ser dividido.

4.2.2. Tokio.

Tambien basado en la ITL e influenciado por Tempura, se presenta ellenguaje Tokio para descripcion de componentes hardware propuesto porAoyagi, Fujita, and Moto-oka [4].

Los operadores principales de Tokio son:

concurrency(, ), la clausula P :- Q, R significa que Q y R son ejecuta-dos al principio de un intervalo de tiempo de manera concurrente.

chop(&&), operador que divide un intervalo de tiempo en dos subin-tervalos. La clausula P :- Q && R significa que Q sera ejecutado alprincipio del primer subintervalo y R al principio del segundo.

next(@), la clausula P :- @Q significa que Q sera ejecutado en el inter-valo de tiempo inmediatamente posterior al actual.

always(#), la clausula P :- #Q significa que Q se ejecutara en todoslos subintervalos que componen el intervalo de P.

sometime <>, la clausula P :- <>Q significa que Q sera ejecutado enalgun momento en el intervalo en que P es ejecutado.

21

4.3 Programacion en logica reificada. 4 PROGRAMACION LOGICA.

keep, la clausula P :- keep(Q) significa que Q sera ejecutado en cadasubintervalo de P excepto en el final.

final(fin), la clausula P :- fin(Q) significa que Q solo sera ejecutadoen el intervalo final de P.

Los intervalos pueden ser manipulados usando determinados operadores de-finidos en el lenguaje como length, empty y notEmpty. La ejecucion de unprograma Tokio es una mezcla de resolucion y reduccion. En lo relativo a launificacion de variables, al igual que en Tempura, estas pueden variar conel tiempo, por lo que el proceso de unificacion es complicado y se divide endos tipos: uno para unificar dos valores de variables Tokio, y el otro usandodirectivas especiales para unificacion de variables en momentos especıficos.

4.3. Programacion en logica reificada.

Con la finalidad de completar un catalogo basico de opciones en progra-macion logica, incluimos tambien dos implementaciones no basadas en losconceptos clasicos de la logica temporal, de intervalos o no.

4.3.1. Temporal Prolog de Hrycej.

Hrycej tambien desarrollo una extension a la que llamo Temporal Pro-log [40], aunque en esta ocasion no estaba basada directamente en logicatemporal, sino que implementa la semantica de la logica temporal en Prolog,siendo capaz de manejar sentencias logicas referenciadas temporalmente yrestricciones temporales.

Al igual que las anteriores Temporal Prolog, tambien esta construido sobreProlog introduciendo en este caso dos tipos adicionales de clausulas:

Referencias temporales , usadas para afirmar que se tiene una ciertasentencia exactamente durante un intervalo de tiempo.

Restricciones temporales , que permiten crear axiomas para las relacio-nes entre los intervalos de tiempo.

El propio Hrycej senalo en [40] como aplicacion de su extension la planifica-cion y consulta de bases de datos, ası como la potencial aplicacion en fısicacualitava [41].

22

4.3 Programacion en logica reificada. 4 PROGRAMACION LOGICA.

4.3.2. Starlog.

Starlog es un lenguaje de programacion temporal capaz de manejar al-gunos problemas en los que el tiempo tiene una papel fundamental. Al igualque el anterior, tampoco esta basado directamente en la logica temporal,de hecho, siquiera proporciona operadores temporales, sino que simplementeanade un argumento adicional a cada predicado de Prolog [21].

23

5 REPRESENTACION DEL CONOCIMIENTO.

5. Representacion del conocimiento.

Sowa defiende que, dado un dominio, la tarea de construir sobre el modeloscomputables usando para ello la logica y las ontologıas es lo que conocemoscomo representacion del conocimiento [77]. Insiste en la importancia de es-tablecer relaciones entre el conocimiento del mundo real y modelos capacesde ser computados. Tanto es ası que llego a proponer un tipo especial degrafos, a los que llamo grafos conceptuales, como la representacion universaldel conocimiento [78].

Valga esta mencion para ilustrar la importancia, la relevancia y la ade-cuacion de los grafos para la representacion del conocimiento, lo que es unaaproximacion habitual en Inteligencia Artificial [17]. En nuestro caso, sin em-bargo, las bases de conocimiento que se suelen manejar en la programacionlogica son, por ası decirlo, mas planas. A modo de ejemplo, las bases de co-nocimiento en Prolog no son mas que sucesiones de hechos que se dan porvalidos escritos, en principio, sin ninguna relacion semantica entre ellos.

No obstante, cuando se trata de logicas temporales la situacion varıa unpoco, ya que es necesario expresar la nocion de temporalidad, algo quecomunmente se ha venido haciendo representando los estados σi del inter-alo σ como nodos de un grafo cuyas aristas denotan no solo el paso de unestado a otro, sino el transcurso del tiempo. Veremos a continuacion dos delas construcciones mas habituales para almacenar la dinamicas temporalessobre las que posteriormente podremos verificar proposiciones.

5.1. Sistemas de transicion etiquetados.

Un sistema de transicion etiquetado (LTS de sus siglas en ingles) es basi-camente un grafo dirigido con etiquetas en las aristas, donde los estadosequivalen a los vertices y las transiciones etiquetadas a las aristas con eti-quetas. Se utilizan a menudo para definir el comportamiento de un procesoque cambia en el tiempo. Los estados modelan los estados del sistema y lastransiciones etiquetadas modelan las acciones llevadas a cabo por el sistema.

24

5.2 Estructuras de Kripke.5 REPRESENTACION DEL CONOCIMIENTO.

Un sistema de transicion etiquetado sobre el conjunto de acciones A y elde predicados P , es una tripleta 〈S,→, |=〉 donde [81]:

S es un conjunto no vacıo y numerable de estados.

→ es una coleccion de relaciones binarias (transiciones)a−→⊆ S×S –una

para cada a ∈ A–, tales que ∀s ∈ S, {t ∈ S|s a−→ t} es un conjunto.

|=⊆ S ×P , de forma que s |= p signidica que el predicado p ∈ P se daen el estado s ∈ S.

Informalmente, una transicion se da cuando el sistema se encuentra en unestado si que puede efectuar la accion al y entonces va al estado sj. Lo

denotamos por sial−→ sj, es decir, hay una transicion etiquetada por a desde

el estado si al estado sj. Si, ademas, desde el estado sj existe una transicion

etiquetada con am tal que sjam−→ sk, entonces se puede componer la notacion

y escribir sial−→ sj

am−→ sk, o lo que es lo mismo, sialak−−→ sk. En general, la

composicion de transiciones se puede expresar como s1a1a2...an−−−−−→ s2.

Conviene resaltar la importancia del no determinismo de los sistemas detransicion etiquetados, ya que incluso tomando la misma secuencia de accio-nes el sistema puede acabar en estados distintos.

5.2. Estructuras de Kripke.

Podemos decir que una estructura de Kripke es un sistema de transicionetiquetado donde el conjunto de transiciones solo consta de una relacionbinaria simple sobre S. Este tipo de estructuras de Kripke son las usadasen logica modal y, por tanto, en logica temporal. Aunque no son las unicasque existen. Si por ejemplo permitimos que A sea un conjunto arbitrario deacciones tendrıamos estructuras de Kripke para logica polimodal.

Formalmente, definimos una estructura de Kripke sobre los conjuntos Ay P de acciones y predicados respectivamente, como una 4-tupla M =〈S, I, T, l〉 donde:

S es el conjunto de estados.

I ⊇ S denota el conjunto de estados iniciales.

25

5.2 Estructuras de Kripke.5 REPRESENTACION DEL CONOCIMIENTO.

T ⊇ S × S es una relacion de transicion entre estados.

l : S → P(A) es la funcion de etiquetado de estados que asigna a cadaestado un proposicion de A.

Las estructuras de Kripke pueden usarse para modelar la semantica de lalogica, usando por ejemplo los habituales operadores X (next time), F (even-tuality), G (globally), U (until), y R (release) [12]. Para ello podemos re-presentar cada estado como un vector s = 〈s(1), . . . , s(n)〉, donde cada s(i)con i = 1, . . . , n es una variable proposicional, y establecer que cada estadotenga un estado sucesor, es decir ∀s ∈ S,∃t ∈ S de manera que 〈s, t〉 ∈ T ,lo que tambien podemos escribir como s ← t. Dada una secuencia infinitade estados π = 〈s1, s2, . . .〉, definimos π(i) = si y π = (si, si+1, . . .)∀i ∈ N.Una secuencia infinita de estados π es un camino si π(i)← π(i + 1) ∀i ∈ N.Decimos que la formula f es valida a lo largo de π, denotado como π |= f , sipara el camino π en la estructura de Kripke M podemos decir:

π |= p si y solo si p ∈ l(π(0))

π |= ¬p si y solo si p /∈ l(π(0))

π |= f ∧ g si y solo si π |= f y π |= g

π |= f ∨ g si y solo si π |= f o π |= g

π |= Gf si y solo si ∀i, πi |= f

π |= Ff si y solo si ∃i, πi |= f

π |= Xf si y solo si π1 |= f

π |= fUg si y solo si ∃i[πi |= g y ∀j < i, πj |= f ]

π |= fRg si y solo si ∀i[πi |= g o ∃j < i, πj |= f ]

De esta manera, una formula f es universalmente valida en una estructurade Kripke M , y denotamos M |= Af , si y solo si π |= f∀π ∈ M,π(0) ∈ I.Por otra parte, es existencialmente valida, M |= Ef , si y solo si π |= f∃π ∈M,π(0) ∈ I

26

5.3 Consideraciones. 5 REPRESENTACION DEL CONOCIMIENTO.

5.3. Consideraciones.

Aunque como hemos visto las estructuras de Kripke son una forma desistema de transicion etiquetado, De Nicola y Vaandrager [25] desarrollaron lalogica ACTL* para sistemas de transcion etiquetados, probando ser igual depotente que CTL* [28], una logica interpretada sobre estructuras de Kripke.En su trabajo establecen dos metodos para mapear estructuras de Kripke asistemas de transicion etiquetados y viceversa, ası como sendas funciones detransformacion entre las dos logicas preservando los valores de verdad.

Por tanto, resulta indiferente cual de las dos construcciones escojamospara la representacion del conocimiento, puesto que son, de hecho, estruc-turas equivalentes con el mismo poder expresivo. Siendo ademas ambas ca-sos especıficos de grafos etiquetados, las dos pueden ser representadas sobrecualquiera de las bases de datos en grafo existentes. Para nuestro proposi-to tomaremos las estructuras de Kripke como la manera de representar elconocimiento.

27

6 BASES DE DATOS EN GRAFO.

6. Bases de Datos en Grafo.

Como senalan Orgun & Ma [64], la potencia de las logicas temporalesya ha sido satisfactoriamente probada en la resolucion de problemas comola especificacion y verificacion de programas [46, 54], el razonamiento tem-poral [18, 73], la inteligencia artificial [76, 6] o las bases de datos tempo-rales [22, 82, 33]. Sin embargo, aunque en este ultimo campo se han hechograndes avances, la mayorıa de las aproximaciones a sistemas de consulta hanseguido las directrices del algebra relacional, el lenguaje SQL, la linguısticacomputacional o incluso el calculo de dominios por ejemplos [65]. Es decir,ninguna de las propuestas ha abandonado el paradigma de las habitualesbases de datos relacionales, transacionales o no. Ocasion de mas para pre-guntarse que pueden ofrecernos a este respecto las nuevas bases de datos norelacionales [79] y, en concreto, las bases de datos basadas en grafo, cuyoslenguajes de consulta estan fuertemente inspirados en repositorios de datoslibres de esquema y algoritmos sobre grafos.

Dentro del grupo de las recien nombradas bases de datos NoSQL [80](acronimo que se acerca mas a una invitacion a completar el ya anciano len-guaje de consultas que a un posicionamiento en su contra –((Not only SQL))en lugar de ((No to SQL)) [27]), podemos encontrar una nueva generacion demotores de bases de datos disenados y construidos con herramientas actualesy manteniendo en mente desde un principio la escalabilidad, la latencia derespuesta, la fiabilidad y la replicacion como los puntos centrales. En estesentido va la queja de Michaek Stonebraker et al. cuando concluye que ((laslıneas de codigo de los actuales sistemas gestores de bases de datos, mientrasintentan ser una solucion ((que se ajuste a todo)), de hecho, no se ajustan anada)), en el sentido de que no pueden competir con las soluciones especıficasque existen en el mercado. Esto, unido al incipiente desarrollo de un siste-ma para procesado online de transacciones (OLTP) denomiando H-Store,supuso un punto de inflexion en el actual panorama de las bases de datos,produciendose el salto definitivo hacia la nueva generacion.

Es en este nuevo paradigma en el que se situan las bases de datos que basansu estructura y funcionamiento en la teorıa de grafos. Sin embargo no son

28

6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.

las mas populares, puesto que por las necesidades de los sistemas actualesse suelen demandar otro tipo de caracterısticas, como las almacenes o cachesclave-valor, los servidores de estructuras, las bases de datos documentalesu orientadas a objetos, y los almacenes de tuplas y por columnas [80]. Noobstante, el desarrollo teorico de los modelos para bases de datos basadasen grafo es muy anterior. Podemos decir que un modelo de base de datos engrafo es aquel en el que o bien las estructuras de datos, o bien los propiosdatos en sı (instancias de la base de datos), o ambos, son modelados comografos (dirigidos y/o etiquetados) o como estructuras de datos con la nocionde grafo (hipergrafos o hipernodos) [3]. Ademas los datos se manipulan atraves de una serie de primitivas de transformacion sobre el grafo.

El tercer punto clave en los modelos de bases de datos en grafo es la inte-gridad de la informacion, ya que suelen existir mecanismos que garanticen dealguna manera la consistencia de los datos respecto del esquema, mantenganla integridad referencial y de los identificadores, y satisfagan las dependenciasfuncionales y de inclusion [34, 47, 50, 42]. Pero no siempre son necesarios.Las nuevas bases de datos basadas en grafo suelen ser denominadas, de he-cho, libres de esquema, ya que cualquier restriccion que coarte la libertad ala hora de introducir los datos y las relaciones entre ellos debera colocarseen una capa superior a la de la persistencia, ya que no implementan (o nosuelen implementar) tales restricciones.

En estos entornos, reflejar cualquiera de las estructuras definidas en lassecciones 5.1 y 5.2 resulta trivial, puesto que como senalamos anteriormenteambas construicciones son casos particulares de grafos etiquetados.

6.1. Bases de datos.

Aunque puede parecer un campo de reciente creacion, las bases de da-tos en grafo cuentan con una buena lista de opciones que han demostradoser satisfactorias desde el punto de vista de las necesidades del mercado. Acontinuacion describimos algunas de las mas populares.

29

6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.

6.1.1. DEX.

DEX3 [55] es, segun sus creadores, una ((biblioteca de alto rendimeintopara gestionar grandes grafos o redes)), en concreto, soporta multigrafos diri-gidos y etiquetados con atributos. De origen academico, desde marzo de 2010DEX es mantenida y comercializada por la companıa Sparsity-Technologies4,una entidad saliente de la Universidad Politecnica de Cataluna.

Desarrollada por y para Java, tiene bindings para la plataforma .NET R©,de Microsfot R©, y es capaz de funcionar en plataformas Windows R© y Linux.Su licencia es unicamente propietaria, aunque la descarga gratuita por mo-tivos de investigacion y evaluacion sı esta permitida. Completamente librede esquema, permite la ejecucion de traversals como metodo de consulta,aunque no proporciona un lenguaje especıfico para ello.

6.1.2. FlockDB.

Inicialmente desarrollada para la red social twitter5 [67], FlockDB6 esuna base de datos en grafo para la gestion de datos a escala Web. El sistemaesta construido para ser totalmente distribuido, tolerante a fallos y bajo lapropuesta teorica MapReduce [24].

Liberada como sofware libre bajo una licencia de tipo Apache7, los desa-rrolladores del proyecto defienden que es mucho mas simple que el resto debases de datos en grafo existentes, tanto es ası que hasta mediados de 2011no contaba aun con un lenguaje de consulta para grafos.

6.1.3. HyperGraphDB.

HyperGraphDB8 es un framework de almacenamiento basado en hiper-grafos generalizados como modelo de datos subyacente. Se podrıa pensar ensu modelo de datos como un modelo relacional en el que se permiten rela-ciones n-arias de un orden superior; o como un modelo orientado a grafos

3DEX: http://sparsity-technologies.com/dex4Sparsity-Technologies: http://www.sparsity-technologies.com5Twitter: http://twitter.com6FlockDB: https://github.com/twitter/flockdb7Apache Licenses: http://www.apache.org/licenses/8HyperGraphDB: http://www.hypergraphdb.org/index

30

6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.

donde las aristas pueden apuntar a un conjunto arbitrario de nodos y deotras aristas. La unidad de almacenamiento es una tupla compuesta de 0 omas tuplas donde cada una es llamada un atomo. Cada atomo tiene un va-lor arbitrario y fuertemente tipado asociado. El sistema de gestion de tiposde esos valores esta embebido como un hipergrafo y se puede modificar encualquier momento.

HyperGraphDB es en sı misma una base de datos embebida con un fra-mework de distribucion basado en el protoclo XMPP9, que ademas funcionainternamente con un almacen clave-valor: una base de datos BerkeleyDB [61].En su forma actual esta concebida como base de datos orientada a objetospara Java. El almacenamiento, el indexado y el cacheo han sido disenadospara permitir consultas sobre el grafo bien por recorridos (traversals) o porcoincidencia de patrones (pattern matching).

Disponible para las plataformas Windows, MacOS y Linux, esta licenciadobajo los terminos de la Lesser GPL10.

6.1.4. InfoGrid.

Pensada para la Web, InfoGrid11 cuenta con varios componentes adicio-nales que pretenden facilitar el desarrollo de aplicaciones web RESTful [69]sobre grafos. Algunos de estos componentes son:

Graph Database Project. Desarrolla el nucleo de InfoGrid. Puede usarsede manera autonoma como base de datos en grafo o en conjuncion conotros proyectos.

Grid Project. Aumenta la capacidad de la base de datos en grafo conun protocolo para replicacion, de manera que diferentes bases de datospuedan colaborar gestionando grafos realmente grandes.

Stores Project. Proporciona una interfaz comun para distintas tecno-logıas de almacenamiento tales como bases de datos SQL y tablas hash

9XMPP Standars Foundation: http://xmpp.org/10GNU Lesser General Public License: http://www.opensource.org/licenses/

lgpl-3.0.html11InfoGrid: http://infogrid.org/

31

6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.

NoSQL distribuidas. Permite, por tanto, dotar de varios sistemas dife-rentes de almacenamiento pero con la misma API para los desarrolla-dores.

Model Library Project. Define una biblioteca de modelos de objetosreusable que pueden ser utilizados como esquemas en las aplicaciones.

Con una licencia Affero GPL12, InfoGrid ofrece opciones de soporte comer-cial a traves de la companıa NetMesh 13.

6.1.5. InfiniteGraph.

InfiniteGraph14 es una base de datos en grafo distribuida disenada parasoportar aplicaciones que generan modelos de datos en grafo, complejos ycon un gran volumen. Proporciona la capacidad de reducir la escala de losmodelos de datos y grafos en multiples bases de datos y multiples grafos.

Soporta una variedad de implementaciones de sistema y despliegues, co-mo pueden ser sistemas basados en servidores, plataformas en la nube oaplicaciones embebidas. Ofrece una API dedicada para uso directo con elmodelo de datos en grafo junto con una capa de persistencia distribuida yaltamente escalable. Mientras que su arquitectura esta disenada para sopor-tar requisitos de alto rendimiento y escalabilidad, la API es muy simple yen principio solo requiere de un mınimo esfuerzo de desarrollo y diseno paraque los programadores puedan construir rapidamente los sistemas segun susnecesidades.

La companıa que se encarga de la licencia de la base de datos es Objectivity,Inc. 15, de la que forma parte InfiniteGraph desde el ano 2010.

12GNU Affero General Public License: http://www.gnu.org/licenses/agpl-3.0.

html13NetMesh: http://netmesh.us/14InfiniteGraph: http://www.infinitegraph.com/15Objectivity, Inc.: http://www.objectivity.com/

32

6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.

6.1.6. Neo4j.

La base de datos Neo4j16 es quizas una de las mas conocidas y activamentedesarrolladas, en la que la fuerte implicacion de la comunidad proporciona elempuje necesario para que avance en las direcciones que los desarrolladoresdemandan.

Neo4j es una base de datos en grafo NoSQL de alto rendimiento, con to-das las caracterısticas de una base de datos robusta y madura. De cara alprogramador, ofrece una buena orientacion a objetos y una estructura de redflexbile, en lugar de estrictas tablas estaticas. Sin embargo, sigue proporcio-nando todos los beneficios de las bases de datos empresariales y completa-mente transacionales. Senalan en su web que incluso hay estimaciones sobreotras bases de datos relacionales que arrojan mejoras del orden del 1000 %en velocidad, aunque tales referencias no han podido ser contrastadas.

Es un proyecto de codigo abierto disponible bajo una licencia GPL v3 parasu edicion Community, y con ediciones Advance y Enterprise disponiblescomo Affero GPL y con soporte por la companıa Neo Technology 17 bajo unalicencia comercial.

6.1.7. OrientDB.

OrientDB18 es un sistema gestor de bases de datos documentales y engrafo escalable y que presume de ser tan flexible como las bases de datosdocumentales y tan poderosa para gestionar enlaces como las bases de datosen grafo. Puede trabajar en modo libre de esquema, con soporte completode esquema o en un modo mixto. Soporta caracterısticas como transaccionesACID [38], ındices rapidos, y consultas nativas y SQL. Importa y exportadocumentos en formato JSON19.

El algoritmo de indexado es de invenvion propia. Recibe el nombre deMVRB-Tree y es una derivacion del Red-Black Tree [75] y los B+Tree [9] perocon las ventajas de ambos: insercion rapida y busquedas aun mas rapidas.

16Neo4j: http://neo4j.org/17Neo Technology: http://neotechnology.com/18OrientDB: http://www.orientechnologies.com/19JSON, JavaScript Object Notation: http://json.org/

33

6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.

El motor transacional puede ser ejecutado en sistemas distribuidos y soportavarios billones de registros con una capacidad maxima de billones de terabytesde datos distribuidos en multiples discos en multiples nodos.

OrientDB es de libre uso y esta distribuida bajo los terminos de una licenciaApache 2.020.

6.2. Lenguajes de consulta.

Por desgracia, en el terreno de las bases de datos en grafo no existe, al con-trario que en las relacionales, un lenguaje de consulta comun estandarizadoy completo que cumpla con los requisitos de las distintas implementaciones.Si bien se han hecho intentos, estos han resultado ser por un lado incom-pletos y por otro demasiado especıficos a una tecnologıa o disposicion de losdatos concretos. Es por ello que no podemos solo describir uno solo sino va-rios de los lenguajes de consulta desarrollados para atacar bases de datos einformacion dispuesta a modo de grafo.

6.2.1. GQL.

GQL [66] es un lenguaje de consultas grafico basado en el modelo de datosfuncional y que puede expresar todas las consultas del algebra relacional.

6.2.2. GraphLog.

Basandose en la representacion en grafo tanto de datos y como de consul-tas, Consens y Mendelzon definieron el lenguaje de consultas llamado Graph-Log [23]. En GraphLog, las consultas son patrones de grafos y las aristas enlas consultas representan caminos en la base de datos.

A dıa de hoy no parece existir una implementacion de referencia funcio-nal y correcta. El sistema gestor de bases de datos Oracle anadio soportepara GraphLog [49], pero se desonoce si los fundamentos que usaron son losmismos que los expuestos a nivel teorico.

20Apache License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0.html

34

6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.

6.2.3. Gremlin.

Basado en el algebra de caminos definida en [70], Gremlin es un lenguajepara atravesar grafos (traversal). Permite consultar un grafo y puede ex-presar traversals complejos con poco esfuerzo, por lo que resulta util paraexplorar y aprender sobre grafos. Mas extensivamente, la idea de aplicar elalgebra de caminos a las redes multi-relacionales ya ha sido explorada conexito en [15, 53].

Desde el punto de vista tecnico existen varias implementaciones, aunquese trata de un lenguaje que puede ser usado sobre distinas bases de datos.Lo que permite independizar las consultas del backend de datos especıfico.

Por otra parte Gremlin es Turing-completo y proporciona numerosas cons-trucciones en memoria y computadas para soportar reconimiento de patronesarbitraros.

6.2.4. PQL.

Como se describe en [23, 57], el origen de PQL esta en el proyecto deintegracion de datos geneticos GeneSeek. PQL incorpora muchas de las ca-racterıstica de los lenguajes de consultas para datos semi-estructurados ygeneraliza el lenguaje StruQL, un lenguaje de consulta tambien para datossemi-estructurados como el XML que permite construir caminos arbitrariossobre las relaciones en un documento sencillo.

A esto se le anade la habilidad de expresar restricciones sobre los metadatoscomo una mejora sobre la curacion de base de datos. Estas restricciones guıanla generacion dinamica de planes de consulta potenciales, lo que permite queuna consulta simple permanezca siendo practicamente la misma incluso enpresencia de esquemas que estan continuamente evolucionando, como es amenudo el caso de la integracion de datos.

6.2.5. SPARQL.

El World Wide Web Consortium (W3C) creo en 2004 el protocolo SPARQLy el lenguaje de consultas RDF [68]. RDF es un formato de datos en grafoetiquetado y dirigido para la representacion de la informacion en la Web. Se

35

6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.

suele utilizar para representar, entre otras cosas, informacion personal, redessociales, metadatos sobre artefactos digitales, ası como para proporcionar unmedio de integracion sobre orıgenes dispares de informacion. SPARQL, es ellenguaje de consulta para RDF, esta disenado para reunir los casos de usoy requisitos identificados por el grupo de trabajo de RDF Data Access. Ellenguaje esta relacionado ıntimamente a las siguientes especificaciones:

La especificacion del Protocolo SPARQL para RDF (SPORT) que de-fine el protocolo remoto para efectuar consultas SPARQL y recibir losresultados.

La especificacion SPARQL Query Results XML Format (RESULTS)que define el formato de un documento XML para representar los re-sultados de las consultas SPARQL SELECT y ASK.

6.2.6. UnQL/UnCAL.

UnQL es una propuesta de lenguaje de consulta sobre datos semi-estructuradosy XML [13] con una sintaxis similar a SQL. Funciona sobre las bases de larecursion estructural y el pattern matching de forma muy parecida a comolo hace XLS sobre ficheros XML pero defininiendo mecanismos para evitarentrar en bucles infinitos durante la evaluacion. El algebra interna de UnQLse denomina UnCAL y define el concepto de recursion estructural sobre gra-fos para, posteriormente, poder efectuar consultas sobre el conjunto de datosaplicando la nocion de que una consulta UnCAL es en realidad una bisimu-lacion generica.

Las consultas UnCAL son computables en NLOGSPACE, esto es, PTIME,pero lamentablemente la unica implementacion real de UnQL, pese a lasindicaciones acerca de las dos formas posibles de evaluar una consulta UnQL,es la desarrollada por los propios autores para el Standard ML [5]. Por lo queconviene no confundirlo con el sistema de identico nombre21 desarrollado porla companıa de reciente aparcion Couchbase22 para consultar bases de datossemi-estructuradas, ficheros en formato JSON y bases de datos documentales.Nada, por el momento, para bases de datos en grafo.

21UnQL: http://www.unqlspec.org/display/UnQL/Home22Couchbase Server 2.0: http://www.couchbase.org/get/couchbase/2.0.0

36

7 LOGICA TEMPORAL DE INTERVALOS Y CONSULTA DEGRAFOS.

7. Logica temporal de intervalos y consulta

de grafos.

Una vez definidos todos los conceptos necesarios, pasaremos a mostrarcomo a partir de estos es posible traducir automaticamente desde una pro-posicion expresada en un lenguaje temporal a la correspondiente expresionen lenguaje de consulta de grafos. A modo de aproximacion se usaran paranuestros propositos la Logica Temporal de Intervalos en la que se basa el len-guaje Tempura, y el lenguaje de consultas Gremlin, de manera que nuestraestructura de Kripke pueda estar alojada en cualquiera de las bases de datossoportadas por Rexster 23.

Usaremos ademas como backend de persistencia la base de datos Neo4j(seccion 6.1.6), de manera que los estados iniciales de las estructuras de Krip-ke vengan denotados por los nodos relacionados con el nodo de referencia deesta base de datos en grafo. Los estados finales no estaran marcados de ma-nera alguna debido a que la longitud de cada camino a verificar dependera dela consulta que se desee efectuar.

7.1. Estructuras de Kripke sobre bases de datos grafo.

Dadas las estructuras de Kripke vistas anterioremente y la potencia yversatilidad de los sistemas de bases de datos basados en grafo, no resultamuy complicado reflejar las primeras en los segundos. De esta manera, sivolvemos a la definicion de la seccion 5.2, podemos decir que una estructurade Kripke es una 4-tupla M = 〈S, I, T, l〉 donde:

S es el conjunto de nodos en la base de datos en grafo.

I ⊇ S el conjunto de nodos marcados como inicial, esto es, que tie-nen una relacion entrante desde el nodo de referencia marcada con laetiqueta initial.

23Rexster [70] es un servicio que proporciona una interfaz REST [30] uniforme paraimplementaciones de bases de datos en grafo. Ofrece la posiblidad de utilizar el lenguajede consultas Gremlin en todas ellas.

37

7.2 Logica temporal sobre lenguaje de consultas para grafos.7 LOGICA TEMPORAL DE INTERVALOS Y CONSULTA DE

GRAFOS.

T es una relacion entre dos nodos etiquetada siempre con next.

l sera el diccionario que mantiene que propiedades estan en cada no-do, es decir, mantiene los valores de los atomos en cada estado. Enla practica esta funcion es innecesaria ya que los nodos mantienen lainformacion sobre sus atributos de manera interna.

7.2. Logica temporal sobre lenguaje de consultas paragrafos.

Como segundo paso antes de construir un algoritmo para conversion,necesitamos establecer las equivalencias entre la sintaxis, los modelos, lasinterpretaciones y la satisfactibilidad de la logica temporal de intervalos yen lenguaje de consultas escogido. Sea entonces v el nodo de referencia de labase de datos, que serıa expresado como v = g.v(0) en Gremlin.

Definimos ademas un dominio D en el que sea posible operar no solo con losvalores de verdad true (verdadero) y false (falso), sino con todo el abanico deoperaciones aritmeticas. De esta manera, no basta con establecer un funcionsimple esperando a que esta se evalue en 0, 1, cada funcion, para que seacorrecta en nuestra propuesta, debe constar al menos de un operador logicocomparador, entendiense como tales la igualdad, la desigualdad, mayor que,menor que, mayor o igual que y menor o igual que. La negacion, como veremosmas adelante, no sera tenida en cuenta y sera tarea del lector efectuar loscambios necesarios para que su proposicion siga siendo correcta.

7.2.1. Sintaxis.

Las expresiones se construiran de la siguiente manera:

Las variables individuales pasan a ser propiedades de los nodos. Noexisten propiedades con valores nulos, es decir, toda propiedad sera unvalor numerico, un valor logico o, en su defecto, una cadena de carac-teres.

Las funciones que implican variables se evaluan usando la aritmeticanativa de los lenguajes.

38

7.2 Logica temporal sobre lenguaje de consultas para grafos.7 LOGICA TEMPORAL DE INTERVALOS Y CONSULTA DE

GRAFOS.

Operador ((siguiente)) (next): ahora toma el significado de, a partir deun nodo, se alcanza el siguiente si desde el primero sale una relaciondirigida hacia el segundo etiquetada con next y en el se cumple cier-ta formula. En principio no es estrictamente necesario que la relacioneste etiquetada, para ası dejar la puerta abierta a futuras relacionescomo previous, que podrıan anadir una semantica mucho mas rica.

Los predicados pasan a ser comprobaciones sobre propiedades y fun-ciones construidas sobre estas, de manera que suponemos definidas re-laciones como ≤ en el lenguaje de consultas.

La igualdad se hara conforme a los operadores logicos definidos en ellenguaje de consulta.

Conectivas logicas: ¬w y wi ∧ wj. Si bien, la unica primitiva real queadmitiremos sera la conjuncion, ya que la negacion puede obtenersemodificando las formulas y proposiciones para producir el resultadoopuesto, esto es, cambiar = por 6=, < por ≥, y > por ≤.

Operador ((siempre)) (always): se interpretara como formulas que sedeben verificar en todos los nodos a partir de aquel en el que sea es-tablecido el operador. Independientemente del resto de proposicionesasociadas al nodo, la condicion que acompana a always siempre debeser cierta.

7.2.2. Satisfactibilidad.

Ahora, decimos que una formula w es satisfecha en un grafo σ, o queel grafo σ satisface la formula w si y solo si existe al menos una consultadel grafo que sea posible efectuar, esto es, produzca al menos un caminode longitud distinta de cero. Buena parte de los lenguajes de consulta sobregrafos estan basados en pattern matching, por lo que la definicion de consultaconsiste en enumerar una serie de patrones sobre los nodos y sus relacionesy buscar coincidencias en el grafo. Cada vez que se encuentra un caminoque coincida con el patron definido se devuelve y se sigue inspeccionando elgrafo. Por tanto, la tarea de conversion consiste en realidad en transformar laproposicion logica en un patron que pueda ser buscado en el grafo, de ahı quedefinamos la sintaxis anterior y podamos incluso extender nuevos operadorescomo veremos en la seccion 7.2.3.

39

7.2 Logica temporal sobre lenguaje de consultas para grafos.7 LOGICA TEMPORAL DE INTERVALOS Y CONSULTA DE

GRAFOS.

I=1J=2

I=3J=1

I=3J=1

I=3J=4

I=3J=4

referencenode

next next

nextinitial

I=3J=4

I=3J=1

I=3J=1

next

next

next next

Figura 1: Grafo de estados con varios caminos posibles.

A modo de ejemplo supongamos la proposicion temporal expresada en 16y tomada de [60].

# (�(I = 3) ∧# # (J = 4)) (16)

Que serıa valida en el grafo de la figura 1, pero no lo serıa en el de la figura2, ambos inspirados tambien en la definicion de estados de intervalo en losejemplos de [60].

I=1J=2

I=3J=1

I=3J=1

I=3J=4

I=3J=4

referencenode

next next

nextinitial

next

Figura 2: Grafo de estados simple.

40

7.2 Logica temporal sobre lenguaje de consultas para grafos.7 LOGICA TEMPORAL DE INTERVALOS Y CONSULTA DE

GRAFOS.

7.2.3. Interpretacion.

Las extensiones propias de la logica temporal de intervalos tambien serantenidas en cuenta en nuestra analogıa teorica, pero con ciertos matices.

MσJV K = σ0JV K, donde V es una propiedad. Es decir, el valor de unapropiedad en un grafo es igual a su valor en el nodo marcado comoinicial, siempre que no este contenida en una proposicion o formula queimplique operadores temporales.

MσJ¬wK = true sera cierto si la formula no se cumple en el grafo.Como mencionamos en la seccion 7.2.1, en principio no soportaremos lanegacion como operador, por lo que este tipo de proposiciones deberanser traducidas a su equivalente MσJwK = false.

MσJ#eK = M〈σ1,...,σ|σ|〉JeK, si se tiene que |σ| ≥ 1. De nuevo el valorde #e se deja sin especificar, esta vez, sobre grafos con un solo nodo.En la practica, no contemplar el nodo inicial no tendra ningun efecto,puesto que de existir solo un nodo la consulta resultante nunca produ-cira resultados.

Y algunos de los operadores secundarios tambien pueden ser definidos sinproblema, aunque no todos. Conviene aclarar que, dado que no se conoce deantemano la longitud de los caminos que satisfacen una cierta proposicion,aquellos operadores que deban ser aplicados sobre estados finales lo seran so-bre el ultimo nodo del posible camino, identificado tras contabilizar el numeromaximo de operadores next anidados que se tenga en la proposicion.

MσJ3wK = true. Para definir el operador ((a veces)) comprobamos laformula w en todos los nodos devueltos por la consulta, siendo obliga-torio que al menos se cumpla en uno.

MσJlen(e)K = true ↔ MσJeK = |σ|. El operador longitud tambien seevaluara a posteriori, comprobando el numero de nodos en los caminosdevueltos por la consulta.

wi ∨ wj y wi ⊃ wj usaran las propias conectivas logicas del lenguaje.Para la implicacion habra que hacer uso de su definicion en base a lanegacion y la conjuncion y, a su vez, usar la negacion como el ope-rador logico comparativo opuesto. Por simplicidad, el operador ∨ solopodra ser usado dentro de formulas y no para componer proposiciones

41

7.2 Logica temporal sobre lenguaje de consultas para grafos.7 LOGICA TEMPORAL DE INTERVALOS Y CONSULTA DE

GRAFOS.

que impliquen operadores temporales, ya que esto implicarıa produ-cir un arbol de consultas por cada ocurrencia de la disyuncion. Noscentraremos en casos mas sencillos.

if b thenwi elsewj usara el operador ternario condicional del lenguajesi este lo implementa. En caso contrario se construira con la ((negacion))y la disyuncion y solo para expresiones.

wi ≡ wj no tendra operador equivalente, pero podra obtenerse a partirde (wi ⊃ wj) ∧ (wj ⊃ wi).

empty sera considerado cierto para el (sub)grafo sin nodos o con uni-camente el nodo de referencia.

more, al tratarse del opuesto a empty, sera cierto en (sub)grafos conal menos un nodo distinto al de referencia.

ei gets ej ≡ �(more ⊃ [(#ei) = ej]), recordemos la interpretacion infor-mal de gets como ((llega a ser)), o ((se convierte en)). Por tanto, habra queevaluar si en cada nodo siguiente a aquel en que se tenga ei, se tieneademas ej.

stable e evaluara si la expresion e se tiene en cada nodo del grafo.

halt w comprueba si w se evalua a false en todos los nodos salvo elultimo, siempre sobre los nodos devueltos por la consulta.

ei ≈ ej, se evalua en cada nodo que �(ei = ej). Notese la diferenciafundamental con gets en que ≈ solo evalua en cada nodo los valores delas expresiones que se tengan en ese estado.

finw, establecer condiciones a satisfacer en el ultimo nodo de los ca-minos devueltos.

ei → ej, para la asignacion temporal bastara con comprobar las propie-dades correspondientes en los nodos inicial y final, teniendo en cuentala consideracion inicial sobre los nodos finales.

skipw toma valor true en grafos que tienen un unico nodo sin contaral de referencia.

42

8 LENGUAJE PYTICLI.

8. Lenguaje Pyticli.

Aunque los lenguajes de consultas sobre grafos son bastante potentes,necesitamos una capa intermedia de programacion que admita la sintaxis dela logica temporal de intervalos y la traduzca a una consulta para grafosindependientemente del lenguaje que implemente cada base de datos. A estesublenguaje que establece una interfaz comun para intervalos temporales enPython y al algoritmo que lleva a cabo la conversion lo denominaremos Pyticli(Python Temporal Intervals Common Language Interface).

El lenguaje de programacion Python 24, creado por Guido Van Rossum aprincipio de los anos 90, es un lenguaje intepretado que cuenta con un nucleomuy reducido pero facilmente ampliable con modulos externos denominadospaquetes. Algunos de ellos se incluyen en la distribucion estandar de Pythonde los distintos sistemas operativos. Uno de estos paquetes habituales esast 25, acronimo ingles para arboles de sintaxis abstracta, y que permiteque los programas sean capaces de procesar la gramatica de otros programasescritos en Python proporcionando un conjunto de metodos para parsear,compilar y ejecutar codigo. Esta es la pieza angular de Pyticli. Tomando unaexpresion sintacticamente correcta en Python que represente una proposiciontemporal, la obtencion del arbol asociado es directa mediante el metodoast.parse, por lo que la construccion de la consulta sobre grafos debe ser elresultado de recorrer el arbol convenientemente y establecer las condicionesa cumplir en cada nodo, esto es, el patron equivalente.

8.1. Sintaxis.

Con la idea de simplificar el algoritmo encargado de procesar el arbol desintaxis, el conjunto de operadores y expresiones valido es el mas limitadoposible.

Constantes. Necesarias para disponer que una proposicion sea cierta ofalsa, nuestro lenguaje cuenta con las constantes logicas true y false,ademas de cualquier construccion numerica valida y cadenas de carac-teres, aunque estas ultimas no seran utilizadas de momento. Seran portanto constantes validas true, 7, " cadena " y 1.2e-3.

24Python Programming Language: http://www.python.org/25Abstract Syntax Trees: http://docs.python.org/library/ast.html

43

8.1 Sintaxis. 8 LENGUAJE PYTICLI.

Atomos. Los atomos de nuestras proposiciones, que posteriormenteseran traducidos a propiedades de los nodos, vendran dados por lasmismas reglas que definen varibles en Python. Son atomos validos J,mi variable, propiedadCamelCase y propiedadCon1y2numeros; einvalidos 1variable y ~nCaracterNoValido.

Operadores aritmeticos. Los operadores definidos hasta el momentoson, + (suma), - (resta), * (multiplicacion) y / (division). A los quese incluyen los operadores necesarios para realizar comparaciones, ==(igualdad), != (desigualdad), < (menor que), > (mayor que), <= (menoro igual que) y >= (mayor o igual que).

Operadores logicos. El unico operador logico permitido es la disyuncion,and.

Operadores temporales. Solo dos operadores temporales basicos estandefinidos, next y always, con la correspondiente semantica ya discutidaen secciones anteriores.

Expresiones. Entenderemos como expresiones cualquier operacion aritmeti-ca sobre atomos y constantes que no implique operadores temporales.

Proposiciones. Una proposicion sera una composicion de operadoreslogicos, expresiones y operadores temporales. De esta manera next(J==1and always(I<=2)) sera una expresion no valida que tendrıa que serexpresada como next(J==1) and next(always(I<=2)).

Tambien estara permitido modificar la precendecia asociada a los operadoresutilizando para ello los sımbolos de parentesis ( y ).

Una gramatica aproximada podrıa ser la definida a continuacion:

proposicion ::= temporal

| proposicion AND temporal

;

temporal ::= NEXT expresion

| ALWAYS expresion

| expresion

;

expresion ::= comparacion

44

8.2 Limitaciones. 8 LENGUAJE PYTICLI.

| expresion AND comparacion

;

comparacion ::= aritmetica

| aritmetica COMPARADOR aritmetica

;

aritmetica ::= elemento

| OPERADOR elemento

;

elemento ::= ATOMO

| CONSTANTE

;

Cualquier otro tipo de proposicion, si bien puede ser correcta desde el puntode vista del parser del lenguaje Python, no sera procesada correctamente pornuestro algoritmo y de producir una salida no se garantiza en modo algunoque esta sea valida.

8.2. Limitaciones.

Existen ciertas limitaciones que han de ser tenidas en cuenta. La masimportante es que la finalidad de esta conversion no es generar un grafo queverifique la proposicion, sino, dada una proposicion y un grafo, comprobar sise verifica la proposicion sobre el grafo. De ahı la conversion de proposiciona consulta sobre el grafo.

Por motivos de simplicidad hemos reducido los operadores y sımbolos alconjunto mas basico posible, en resumen, a los operadores ∧, =, next yalways. Mencion especial require la ausencia del operador ¬ (negacion), quepodrıa resultar indispensable para construir ciertas proposiciones. Sin embar-go, esta carencia puede ser suplida con el uso de las constantes true y false yde los operadores de igualdad y desigualdad. Actualmente queda como tareadel usuario de Pyticli hacer la correspondiente transformacion de la consulta,este y otros operadores pueden ser facilmente preprocesados automaticamen-te antes de ser evaluados por Pyticli. Sin embargo, este preprocesado quedafuera del alcance de este documento, aunque en la seccion 8.5 se indicaranalgunas pautas utiles a seguir en pos de una posible implementacion.

45

8.3 Algoritmo de conversion. 8 LENGUAJE PYTICLI.

8.3. Algoritmo de conversion.

El proceso mediante el cual a partir de una proposicion se devuelve unaconsulta sobre grafos consta de varias partes. A grandes rasgos vendrıa descri-to por el algortimo 1. Dado que la funcion AbstractSyntaxTree es invocadadirectamente a traves del metodo parse del paquete de Python ast que pro-duce el arbol de sintaxis correspondiente, el peso de la conversion recae sobrelas funciones ProcessTree y GenerateQuery. Conviene resaltar la importan-cia de las estrucuras auxiliares a y n, ambas diccionarios, que almacenaran lainformacion siguiente una vez que ProcessTree haya terminado su ejecucion:

El diccionario a tendra por claves el numero del nodo (estado) a partirdel cual deben cumplirse las expresiones que tenga definidas en su valorasociado. Esta claves obedecen al orden en el cual ha de construirse elpatron equivalente a la proposicion temporal que se busca traducir.

El diccionario n tambien tendra como claves el numero que designa elnodo en la consulta sobre el grafo, y sus valores seran las expresionesque se han de verificar en cada uno de ellos.

Ambas estructuras usan una representacion abstracta para los atomos y lasconstantes: los numeros son encerrados entre los sımbolos {# y #}, las cadenasde caracteres entre {$ y $}, los valores de verdad entre {< y >}, los atomosque hagan referencia a propiedades del nodo actual entre {{ y }}, los quehagan referencia al nodo anterior entre { % y %}, y los que que se refieren alnodo inicial entre {@ y @} (los dos ultimos casos seran especialmente utilescuando se extienda el lenguaje con funciones como gets o halt). Algunosejemplos son:

Numeros: {#13#}, {#1.4#}, {#-2.4e+10#}.

Cadenas: {$cadena de caracteres$}, {$Caracteres extra~nos$}.

Valores logicos: {<true>}, {<false>}.

Propiedades del estado actual: {{I}}, {{miPropiedad}}.

Propiedades del estado anterior: { %I %}, { %miPropiedad %}.

Propiedades del estado inicial: {@I@}, {@miPropiedad@}.

46

8.3 Algoritmo de conversion. 8 LENGUAJE PYTICLI.

Por su parte, los operadores tambien son transformados a su representacionpor convenio, esto es, & para el operador disyuncion, == para la igualdad, !=desigualdad, < menor, > mayor, <= menor o igual que, >= mayor o igual que,+ suma, - resta, * multiplicacion y / division.

Algorithm 1 Algoritmo general de conversion: Pyticli

Require: p← Temporal Logic PropositionEnsure: q ← GraphDatabaseQuery

1: s← {Empty Stack}2: a← {Empty Dictionary}3: n← {Empty Dictionary}4: t← AbstractSyntaxTree(p)5: ProcessTree(t, s, a, n)6: q ← GenerateQuery(a, n)7: return q

De esta manera la funcion GenerateQuery manipulara los sımbolos si-guiendo este convenio y sera capaz de producir distintas salidas para distintoslenguajes de consulta procesando la proposicion inicial una unica vez. El mo-tivo de esta representacion abstracta intermedia es independizar la generacionde la consulta del parseo del arbol sintactico.

Como se aprecia, el nucleo de funcionamiento de Pyticli es la funcionProcessTree que, a su vez, se apoya en otras tantas auxiliares como indica elalgoritmo 2. Su funcionamiento es relativamente sencillo. Cuando el moduloast de Python produce el arbol sintactico, cada expresion debe ser evaluadaindependientemente, puesto que tienen atributos y metodos distintos. Ası,el parseo de una proposicion puede ser primero dividido en una funcion dedisyuncion u operacion binaria (clase ast.BinOp de Python) en la que se in-dican el operador implicado y las partes derecha e izquierda de la operacion.Lo que es distinto de, por ejemplo, las operaciones logicas o booleanas (claseast.BoolOp), que tienen parte izquierda, y una lista con los comparadores ylos terminos implicados.

Como es habitual, el tratamiento del arbol sintactico se hace de mane-ra recursiva, utilizando una estructura auxiliar, en este caso una pila, en laque se van apilando los elementos indivisibles de cada llamada (las funciones

47

8.3 Algoritmo de conversion. 8 LENGUAJE PYTICLI.

Algorithm 2 Algoritmo de procesado del AST: ProcessTree

Require: t← {Expression Tree}Require: s← {Stack}Ensure: a← {Dictionary for always}Ensure: n← {Dictionary for next}

1: if t is a BooleanOperation then2: sPush ← getOperator(t)3: for value in V alues(t) do4: ProcessTree(value, a, n)5: end for6: if s then7: sPop8: end if9: else if t is a ComparationOperation then

10: for i, comparator in getComparators(t) do11: sPush ← getOperatori(t)12: ProcessTree(getLeftTree(e), a, n)13: ProcessTree(getRightTree(e), a, n)14: s← StackReduce(s, a, n)15: end for16: else if t is a BinaryOperation then17: sPush ← getOperator(t)18: ProcessTree(getLeftTree(t), a, n)19: ProcessTree(getRightTree(t), a, n)20: s← StackReduce(s, a, n)21: else if t is a CallOperation then22: sPush ← getCallerFunction(t)23: for argument in getArguments(t) do24: ProcessTree(argument, a, n)25: s← StackReduce(s, a, n)26: end for27: else if t is an Atom then28: sPush ← getAtom(t)29: end if

48

8.3 Algoritmo de conversion. 8 LENGUAJE PYTICLI.

always, next y las constantes) para luego, al terminar cada llamada recur-siva, invocar a un metodo de reduccion de pila que debera inspeccionar elcontenido de la misma y operar en consecuencia. Este procedimiento, ilustra-do en 3, es el encargado de generar las estructuras abstractas que almacenanla informacion correspondiente a las condiciones a verificar en los estados,tanto para el operador next como always. En cada llamada exitosa a Stac-kReduce, el tamano de la pila disminuye, pasando los elementos eliminadosa formar parte de las estructuras antes mencionadas. El funcionamiento delalgoritmo es sencillo: va extrayendo los elementos de la pila y comprobandoque cada tripleta extraıda se corresponde con una expresion valida, en cuyocaso puede tomar dos decisiones:

La expresion es una operacion aritmetica, en cuyo caso simplemente seanade como un elemento atomico en la pila.

La expresion es una operacion logica, por lo que debera anadirse aldiccionario correspondiente, a para operadores always y n para ope-radores next, junto al operador logico que la acompana si procede. Esdecir, se asume por defecto que las operaciones logicas solo usan eloperador ∧, pero se deja la puerta abierta para soportar la disyuncion.

Si no encuentra una expresion valida que formar con los primeros 3 elementosde la pila, entonces devuelve la pila sin modificar.

El proceso anterior esta tambien apoyado en una baterıa de funcionesy metodos auxiliares de los que hay que destacar la funcion StackSplit,encargada de inspeccionar la pila en busca de llamadas anidades de losoperadores always y next, identificando a partir de que estado o exacta-mente en cuales deben satisfacerse las expresiones a las que acompanan.Por ejemplo, si en un estado concreto de la ejecucion se tiene que la pilas = 〈next, always, next, next, expr〉, sera equivalente a tener siempre expr apartir del estado 3. Sin embargo, aunque esta asuncion puede resultar tri-vial, no ha sido posible localizar una demostracion valida que la sustente enla literatura relacionada, salvo, quizas, algunas nociones parecidas aunque in-completas en [10]. Por tanto, queda su demostracion formal emplazada comotrabajo futuro.

49

8.3 Algoritmo de conversion. 8 LENGUAJE PYTICLI.

Algorithm 3 Algoritmo de reduccion de pila: StackReduce

Require: s← {Stack}Ensure: r ← {Reduced Stack}Ensure: a← {Dictionary for always}Ensure: n← {Dictionary for next}r ← sif sLength ≥ 3 thenright← rPopleft← rPopif left and right are V alidComparators thenoperator ← rPopexpr ← 〈right, operator, left〉if operator is an ArithmeticOperator thenrPush ← exprr ← StackReduce(r, a, n)

else if operator is a LogicOperator thenalways, next, logic← StackSplit(r)if always thenaAdd ← (next, logic, expr)

elsenAdd ← (next, logic, expr)

end ifelser ← s

end ifelser ← s

end ifend ifreturn r

50

8.4 Aplicaciones. 8 LENGUAJE PYTICLI.

8.4. Aplicaciones.

Como se comento en la seccion 1, el presente proyecto no pretende seruna solucion para verificacion de modelos sino, mas bien, una herramientacomplementaria que permita, a partir del grafo de las trazas generadas porun sistema ya en funcionamiento, comprobar si las proposiciones tempora-les usadas en su concepcion siguen siendo verificadas (satisfactibles). Estopermitirıa, por ejemplo, centralizar el repositorio de trazas de un sistemade sensores y consultar en tiempo real si el funcionamiento es el esperadosimplemente recurriendo al conjunto de proposiciones usado en su diseno.

En este sentido, y tomando como base el amplio catalogo de ejemplosde [60], se muestran a continuacion algunas de las correspondencias entreformulas expresadas en ITL y sus equivalentes en Pyticli.

8.4.1. Operadores basicos.

Las primeras formulas de ITL sintacticamente correctas en aparecer sonlas mostradas en (17, 18 y 19).

(J = 2) ∧#(I = 3) (17)

(#�[I = 3]) ∧ ¬([#J ] = 4) (18)

# (�[I = 3] ∧# # [J = 4]) (19)

Las proposiciones equivalentes en Pyticli se muestran en (20, 21 y 22).

(J==2) and next(I==3) (20)

(next(always(I==3)) and next(J!=4) (21)

next(always(I==3) and next(next(J==4))) (22)

Resulta trivial la construccion de proposiciones basicas en Pyticli a partir dela original expresada en ITL, ya que la unica consideracion a tener en cuentaes la negacion, que solo puede aplicarse a las comparaciones. Por tanto, laformula (23) no tendrıa ningun equivalente posible, ya que, como vimos enla seccion 8.5, implicarıa la nocion del operador sometimes.

(J = 2) ∧ ¬�(I 6= 3) (23)

51

8.5 Mejoras al lenguaje. 8 LENGUAJE PYTICLI.

8.4.2. Operadores compuestos.

Aunque con el reducido conjunto de operadores de Pyticli existen cier-tos operadores que no pueden ser expresados, otros tantos, sin emabrgo, nopresentan mayor problema.

Ejemplo: implicacion. Aplicando las construcciones logicas convencio-nales para la conjuncion y la implicacion, podemos reescribir la formula(24) como se muestra en (25).

[#(I = 1) ∧#(J = 2)] ⊃ #(I + J = 3) (24)

(next(I==1) and next(J==2)) ⊃ next(I+J==3)

≡ (next(I==1 and J==2)) ⊃ next(I+J==3)

≡ not(next(I==1 and J==2) and not(next(I+J==3)))

≡ not(next(I==1 and J==2) and next(I+J!=3))

≡ next(I!=1 or J!=2 and I+J==3)

(25)

Ejemplo: estabilidad. Dada (26), la forumla (27) muestra su equivalen-cia.

(I = 1) ∧ stableI (26)

always(I==1) (27)

Ejemplo: longitud de un intervalo. La formula (28) trata de comprobarque la longitud del intervalo es 3.

# # # empty ≡ next(next(next(next(false)))) (28)

8.5. Mejoras al lenguaje.

En aras de la simplicidad, desde el principio del proyecto se tomaron unaserie de decisiones sobre Pyticli que redujeron su versatilidad. Entre estasdecisiones esta la ausencia de soporte para las operaciones de negacion yconjuncion en las proposiciones, el reducido juego de operadores temporalesy el soporte para un unico lenguaje de consulta de grafos como salida, esto es,Gremlin. Sin embargo, gracias a su diseno altamente modular y estructuradoy a la representacion interna de las proposiciones, existen algunas vıas parasolventar estas limitaciones.

52

8.5 Mejoras al lenguaje. 8 LENGUAJE PYTICLI.

8.5.1. Operadores ¬ y ∨.

Actualmente, para hacer uso de la negacion es necesario que el usuariode Pyticli prepare primero su proposicion y expanda las negaciones que en-cuentre en sus expresiones con los correspondientes operadores negados. Deesta manera, usando el algebra de Boole, habrıa que obtener las equivalenciassustituyendo donde proceda == por !=, != por ==, < por >=, y <= por >, > por<=, y >= por <. Este procedimiento podrıa automatizarse dentro de la funcionStackReduce 3, de forma que si el segundo elemento de la pila es el operadorde negacion, todas las comparaciones del primer elemento de la pila debenser sustituidas por su negacion y, finalmente, apilar la nueva expresion. Unmecanismo parecido podrıa seguirse para el operador conjuncion ∨.

Sin embargo conviene resaltar que con el procedimiento descrito solo serıaposible utilizar la negacion y la conjuncion en expresiones que no impli-quen operadores temporales. Esto es, al encontrar una expresion del ti-po not(next(J==2)), nuestra propuesta funcionarıa correctamente, pero encambio no resolverıa correctamente expresiones del tipo not(next(J==2)

and always(I==1)), ya que not(always(I==1)), que serıa equivalente asometimes(I==1), no esta aun contemplado en Pyticli.

8.5.2. Operadores temporales.

Otros operadores temporales como gets, halt o fin sı serıan facilmenteimplementables utilizando las propiedades de los estados inicial, anterior yactual descritas en la seccion 8.3. Otros operadores, como sometimes o equiv

(wi ≡ wj), que requieren de una comprobacion a posteriori sobre los estadosde los caminos posibles devueltos por la consulta, no son tan facilmenteimplementables.

8.5.3. Lenguajes de salida.

Para enriquecer Pyticli con nuevos lenguajes basta con crear una nuevaclase Python que extienda pyticli.languages.BaseQueryLanguage y queimplemente el metodo generate cuyo unico parametro es el valor logicoverbose. Esta clase proporciona en la variable self.states una lista conlas expresiones a satisfacer en cada estado convenientemente abstraıdas ytras haber procesado los operadores temporales.

53

8.5 Mejoras al lenguaje. 8 LENGUAJE PYTICLI.

Como se aprecia en el extracto de codigo 1, una vez se tienen los valoresde self.states, construir la consulta en Gremlin es realmente sencillo, puesbasta con recorrerlos e ir adaptando las expresiones a la sintaxis del lenguajeen cuestion. La funcion flatten es, en este caso, la encargada de traducir lasrepresentaciones abstractas de los atomos a las correspondientes expresionesnativas en Gremlin.

1 def generate ( s e l f , verbose=False ) :2 i f verbose :3 s epara to r = ”\n ”4 else :5 s epa ra to r = ””6 query = ”””g . v ( 0 ) . outE{” i n i t i a l ”}”””7 for i in xrange (0 , s e l f . s t a t e s c o u n t ) :8 query = ” % s % s ” % ( query , s epa ra to r )9 i f i in s e l f . s t a t e s :

10 va l = s e l f . f l a t t e n ( s e l f . s t a t e s [ i ] )11 i f i == 0 :12 query = ” % s . inV{% s } . s i d e E f f e c t { i n i t=i t .map ( ) ; ” \13 ” prev % s=i t . map ( ) } . outE{\” next \”}” \14 % ( query , val , i )15 else :16 query = ” % s . inV{% s } . s i d e E f f e c t {” \17 ” prev % s=i t . map ( ) } . outE{\” next \”}” \18 % ( query , val , i )19 else :20 i f i == 0 :21 query = ” % s . inV . s i d e E f f e c t { i n i t=i t .map ( ) ; ” \22 ” prev % s=i t . map ( ) } . outE{\” next \”}” \23 % ( query , i )24 else :25 query = ” % s . inV . s i d e E f f e c t {” \26 ” prev % s=i t . map ( ) } . outE{\” next \”}” \27 % ( query , i )28 query = ” % s % s . paths . unique ( ) ” % ( query , s epa ra to r )29 return query

Listing 1: Funcion generate de GremlinLanguage

54

8.6 Consola interactiva. 8 LENGUAJE PYTICLI.

8.6. Consola interactiva.

Pyticli cuenta con una consola interactiva o shell aun muy basica perofuncional, con la cual se pueden hacer pruebas de conversion entre propo-siciones e incluso conectar con una base de datos en grafo real a la queatacar directamente. El comportamiento por defecto se limita a, dada unaproposicion en Pyticli para ITL, devolver la consulta equivalente en Gremlin.Soporta, ademas, un reducido conjunto de comandos:

verbose, que puede ir acompanado de on u off y permite activarla impresion de la estructura intermedia utilizada para representar laproposicion de manera abstracta.

connect, con 2 parametros, el primero especifica el tipo de base dedatos a la que se va a conectar, y el segundo la cadena de conexion.De momento solo esta disponible la base de datos Neo4j a traves desu cliente REST para Python26. Una vez que la conexion es estableci-da, cada conversion de proposicion devuelve, ademas, el resultado deejecutar la consulta resultante sobre la base de datos en cuestion.

disconnect, para desconectar de la base de datos si hay alguna cone-xion establecida. Solo una conexion puede estar activa, por lo que esnecesario desconectar cada vez que se quiera cambiar de base de datos.

gremlin, permite efectuar una consulta directamente en Gremlin con-tra una base de datos en grafo en el caso de que se haya conectado conalguna.

help, sin parametros imprime la ayuda general de la consola. Acom-panado de otro comando muestra la ayuda especıfica de este.

exit, para terminar la sesion de la consola.

Una sesion habitual de la consola puede ser la mostrada en 8.6 (el sımbolo:> simboliza la entrada o prompt de la consola).

$ python shell.py

Pyticli 0.0.3 by Javier de la Rosa.

26An Object-Oriented Python Library to Interact with Neo4j Standalone REST Server:http://pypi.python.org/pypi/neo4jrestclient/

55

8.6 Consola interactiva. 8 LENGUAJE PYTICLI.

Licensed under the terms of GPL 3.

More info: http://github.com/versae/pyticli.

:> next(I==2)

g.v(0).outE{"initial"}

.inV.sideEffect{init=it.map(); prev0=it.map()}.outE{"next"}

.inV{ ( it."I" == 2 ) }.sideEffect{prev1=it.map()}.outE{"next"}

.paths

:> connect neo4j http://localhost:7474/db/data

Connected!

:> next(J==1)

g.v(0).outE{"initial"}

.inV.sideEffect{init=it.map(); prev0=it.map()}.outE{"next"}

.inV{ ( it."J" == 1 ) }.sideEffect{prev1=it.map()}.outE{"next"}

.paths

Traversal:

=> [v[0], e[0][0-initial->1], v[1], e[6][1-next->2], v[2], e[8][2-next->7]]

=> [v[0], e[0][0-initial->1], v[1], e[6][1-next->2], v[2], e[7][2-next->3]]

:> verbose on

Verbose enable

:> next(J==1)

g.v(0).outE{"initial"}

.inV.sideEffect{init=it.map(); prev0=it.map()}.outE{"next"}

.inV{ ( it."J" == 1 ) }.sideEffect{prev1=it.map()}.outE{"next"}

.paths

Representation:

=> {1: [(’{{J}}’, ’==’, ’{#1#}’)]}

Traversal:

=> [v[0], e[0][0-initial->1], v[1], e[6][1-next->2], v[2], e[8][2-next->7]]

=> [v[0], e[0][0-initial->1], v[1], e[6][1-next->2], v[2], e[7][2-next->3]]

56

8.6 Consola interactiva. 8 LENGUAJE PYTICLI.

:> exit

Todo el codigo de Pyticli ası como la consola esta liberado bajo unalicencia libre GNU General Public License 27 y disponible en un repositoriode codigo en la plataforma para desarrolladores GitHub 28. Ademas, se haincluido una version inicial en el ındice de paquetes del lenguaje Python 29,de forma que con un simple comando de terminal, pip install pyticli,se pueda tener funcionando. La consola, sin embargo, necesita revision deempaquetado, pues lo deseable serıa que una vez instalada se puede utilizarsimplemente escribiendo pyticli en la terminal de comandos del sistemaoperativo (de momento solo probado solo en sistemas basados en Linux).

27GNU General Public License: http://www.gnu.org/licenses/gpl.html28Python Temporal Intervals Common Language Interface: http://github.com/

versae/pyticli29A Python Temporal Intructions Common Language Interface: http://pypi.python.

org/pypi/pyticli/0.0.3

57

9 CONCLUSIONES Y TRABAJO FUTURO.

9. Conclusiones y trabajo futuro.

En el presente trabajo se han introducido conceptos de logica modal tem-poral y, en concreto, logica temporal de intervalos, que pueden estar sopor-tados por construcciones denominadas estructuras de Kripke. Hemos vistoque existe una equivalencia a nivel de representacion entre estas estructurasy los grafos reproducibles en bases de datos en grafo reales. Con la posbili-dad potencial de almacenar billones de proposiciones formando estructurasde Kripke masivas, Pyticli ofrece un proxy capaz de convertir proposicionesde ITL a consultas sobre el grafo, siendo capaz de generar una respuestasobre la satisfactibilidad de la proposicion. Lo que cuadra con lo propuestoen [84, 85].

Queda como trabajo futuro realizar un analisis mas profundo de las impli-caciones de la equivalencia entre grafos y estructuras de Kripke, y entre ITLy Gremlin.

Por otra parte, serıa interesante estudiar en profundiad las similitudesentre el algebra de caminos y las construcciones en logica temporal, ası comolos modelos de Herbrand [83] para una posible implementacion general delmetodo que pueda extenderse a un lenguaje de consultas teorico sobre lalogica temporal.

58

REFERENCIAS

10. Bibliografıa.

Referencias

[1] M. Abadi & Z. Manna. Temporal logic programming. In Proceedings of the1987 Symposium on Logic Programming, 4–16. IEEE Computer SocietyPress, 1987.

[2] M. Abadi & Z. Manna. Temporal logic programming. Journal of SymbolicComputation, 8:277–295, 1989.

[3] R. Angles & C. Gutierrez. Survey of Graph Database Models. TechnicalReport TR/DCC-2005-10, Computer Science Department, Universidad deChile, 2005.

[4] T. Aoyagi, M. Fujita, & T. Moto-oka. Temporal logic programming lan-guage Tokio. In E. Wada, editor, Logic Programming’85, 221:138–147.Springer-Verlag, 1986.

[5] A. W. Appel & D. B. MacQueen. A standard ml compiler. FunctionalProgramming Languages and Computer Architecture, 1987.

[6] F. Baader. Logic-based knowledge representation. In Artificial Intelligen-ce Today: Recent Trends and Developments, page 13. Springer, 1999.

[7] P. Balbiani, A. Herzig, & M Lima-Marques. TIM: The Toulouse inferencemachine for non-classical logic programming. In PDK’91: InternationalWorkshop on Processing Declarative Knowledge, volume 567 of LNAI,pages 365–382. Springer-Verlag, 1991.

[8] P. Balbiani, A. Herzig, & M. Lima-Marques. Implementing Prolog ex-tensions: a parallel inference machine. In Proc. of the 1992 InternationalConference on Fifth Generation Computer System, pages 833–842. ICOT,1992.

[9] R. Bayer & E. M. McCreight. Organization and Maintenance of LargeOrdered Indices. In Acta Informatica, 1: 173–189. 1972.

[10] P. Blackburn, M. de Rijke & Y. Venema. Modal logic, 53. CambridgeUniversity Press, 2001.

59

REFERENCIAS REFERENCIAS

[11] P. Blackburn, J. van Benthem & F. Walter. Handbook of Modal Logic,53. North Holland, 2006.

[12] M. C. Browne, E. M. Clarke & O. Grumberg. Characterizing finite Krip-ke structures in propositional temporal logic, In Theoretical ComputerScience, 59(1–2): 115–131, 1988.

[13] P. Buneman, M. Fernandez & D. Suciu. UnQL: a query language andalgebra for semistructured data based on structural recursion. In TheVLDB Journal, 9(1): 76–110. Springer, 2000.

[14] J. P. Burgess. Basic tense logic. In D. M. Gabbay and F. Guethner, edi-tors, Handbook of Philosophical Logic, 2(89): 89–134. D. Reidel PublishingCompany, 1984.

[15] B. Carre. Graphs and Networks, Oxford University Press, 1979.

[16] A. Chandra, J. Halpern, A. Meyer & R. Parikh. Equations betweenregular terms and an application to process logic. In Proceedings of theThirteenth Annual ACM Symposium on Theory of Computing, 384–390,Milwaukee, Wisconsin, 1981.

[17] M. Chein & M. L. Mugnier. Simple Conceptual Graphs, Graph-basedKnowledge Representation, series Advanced Information and KnowledgeProcessing, 59–81, Springer London, 2008.

[18] E. Chouraqui. Formal expression of time in a knowledge base. In P.Smets, A. Mamdani, D. Dubois, and H. Prade, editors, Non-StandardLogics for Automated Reasoning, pages 81–103. Academic Press, 1988.

[19] E. M. Clarke, D. E. Long & K. L. McMillan. Compositional model chec-king. In Logic in Computer Science, 1989. LICS’89, Proceedings., FourthAnnual Symposium on, 353–362. IEEE, 1989.

[20] E. Clarke. Model checking. In Foundations of software technology andtheoretical computer science, 54–56. Springetr, 1997.

[21] G. Cleary & V. N. Kaushik. Updates in a temporal logic programminglanguage. Technical report, Department of Computer Science, Universityof Calgary, Calgary, Alberta, Canada, 1991.

60

REFERENCIAS REFERENCIAS

[22] J. Cliford & D. S. Warren. Formal semantics for time in databases. ACMTransactions on Database Systems, 8(2):214–254, June 1983.

[23] M. P. Consens, A. O. Mendelzon, Graphlog: a visual formalism for reallife recursion. In Proceedings of the Symposium on Principles of DatabaseSystems, 404–416. ACM, New York, NY, 1990.

[24] J. Dean S. Ghemawat. MapReduce: simplified data processing on largeclusters, In Commun. ACM 51(1): 107–113, New York, NY, USA, 2008.

[25] R. De Nicola & F. Vaandrager. Action versus state based logics fortransition systems. In Semantics of Systems of Concurrent Processes, 407–410, Springer, 1990.

[26] E. Eifrem. Neo4j – The Benefits of Graph Databases. OSCON pre-sentation, 2009. Accesed on July 2011: http://www.slideshare.net/

emileifrem/neo4j-the-benefits-of-graph-databases-oscon-2009.

[27] J. Ellis. NoSQL Ecosystem. 2009. Accesed on July 2011: http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/.

[28] E. A. Emerson & C.-L. Lei. Modalities for model checking: Branchingtime strikes back. Science of Computer Programming, 8:275–306. 1986.

[29] J. L. Fernandez Vindel, A. Manjarres Riesco & F. J. Dıez Vegas. LogicaComputacional. Dpto. Inteligencia Artificial, E.T.S.I. Informatica. UNED,2007.

[30] R. T. Fielding. Architectural Styles and the Design of Network-basedSoftware Architectures, Doctoral dissertation. University of California,Irvine, 2000.

[31] D. M. Gabbay. Modal and temporal logic programming. In A. Galton,editor, Temporal Logics and Their Applications, 197–237. Academic Press,1987.

[32] D. M. Gabbay. A temporal logic programming machine [modal and tem-poral logic programming, Part 2]. Department of Computing, ImperialCollege, 1989.

61

REFERENCIAS REFERENCIAS

[33] D. Gabbay & P. McBrien. Temporal logic & historical databases. In Pro-ceedings of the 17th Very Large Data Bases Conference, pages 423–430,Barcelona, Spain, September 1991. Morgan Kaufman, Los Altos, Califor-nia.

[34] M. Graves, E. R. Bergeman, & C. B. Lawrence. Graph Database Systemsfor Genomics. In IEEE Engineering in Medicine and Biology. Special issueon Managing Data for the Human Genome Project 11, 6, 1995.

[35] R. Hale. Temporal logic programming. In A. Galton, editor, TemporalLogics and Their Applications, 91–119. Academic Press, 1987.

[36] J. Halpern, Z. Manna & B. Moszkowski. A hardware semantics based ontemporal intervals. In Proceedings of the 10-th International Colloquiumon Automata, Languages and Programming, 154: 278–291, Lecture Notesin Computer Science, Springer Verlag, Berlin, 1983.

[37] J. Halpern, Z. Manna & B. Moszkowski. A hardware semantics based ontemporal intervals. In Proceedings of the 10-th International Colloquiumon Automata, Languages and Programming, 154: 278–291, in the seriesLecture Notes in Computer Science, Springer Verlag, Berlin, 1983.

[38] T. Harder & A. Reuter. Principles of Transaction-Oriented DatabaseRecovery. In ACM Computing Surveys 15(4): 287–317. 1983.

[39] D. Harel, D. Kozen & R. Parikh. Process logic: Expressiveness, decida-bility, completeness. In Journal of Computer and System Sciences, 25(2):144–170, 1982.

[40] T. Hrycej. Temporal Prolog. In Proc. of the European Conference onArtificial Intelligence, 296–301, Munich, Germany, 1988.

[41] T. Hrycej. A temporal extension of Prolog. Journal of Logic Program-ming, 15: 113–145, 1993.

[42] G. Klyne & J. Carroll. Resource Description Framework (RDF) Con-cepts and Abstract Syntax. Accessed on July 2011: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/

[43] R. Kowalski & D. Kuehner. Linear Resolution with Selection FunctionArtificial Intelligence 2: 227-60, 1971.

62

REFERENCIAS REFERENCIAS

[44] R. A. Kowalski. Predicate logic as programming language. In Proceedingsof IFIP’74, 569–574, Amsterdam, 1974.

[45] S. Kripke. Semantical considerations on modal logic. In Acta philosop-hica fennica, 16(1963): 83–94. 1963.

[46] F. Kroger. Temporal Logic of Programs. Springer-Verlag, Berlin Heidel-berg, 1987.

[47] G. M. Kuper & M. Vardi. The Logical Data Model. In ACM Transac-tions on Database Systems (TODS) 18(3): 379–413, 1993

[48] N. Leavitt. Will NoSQL databases live up to their promise?. In Compu-ter, 43(2): 12–14. IEEE, 2000.

[49] U. Leser. A query language for biological networks. Bioinformatics 21(2):33–39. 2005.

[50] M. Levene & A. Poulovassilis. An Object-Oriented Data Model Forma-lised Through Hypergraphs. Data & Knowledge Engineering (DKE) 6(3):205–224, 1991.

[51] S. Litt. ”NoSQL: The Unix Database (With awk)”. Linux ProductivityMagazine, 2007. Accessed on July 2011, http://www.troubleshooters.com/lpm/200704/200704.htm

[52] J. W. Lloyd. Foundations of Logic Programming. Springer-Verlag, 1984.

[53] R. Manger. A new path algebra for finding paths in graphs. In Procee-dings of the International Conference on Information Technology Interfa-ces, 1: 657–662. 2004.

[54] Z. Manna & A. Pnueli. Verification of concurrent programs: the tem-poral framework. In Boyer and Moore, editors, Correctness Problem inComputer Science, pages 215–273. Academic Press, 1981.

[55] N. Martınez-Bazan, V. Muntes-Mulero, S. Gomez-Villamor, J. Nin, M.Sanchez-Martınez & J. Larriba-Pey. 2007. Dex: high-performance explo-ration on large graphs for information retrieval. In Proceedings of theSixteenth ACM Conference on Conference on information and Knowled-ge Management (Lisbon, Portugal, November 06 - 10, 2007). CIKM ’07.ACM, New York, NY, 573-582.

63

REFERENCIAS REFERENCIAS

[56] J. C. C. McKinsey. On the syntactical construction of systems of modallogic. In Journal of Symbolic Logic, 10:83–96, 1945.

[57] P. Mork, R. Shaker, A. Halevy, & P. Tarczy-Hornoch. PQL: a declarativequery language over dynamic biological schemata. In Proceedings of theAMIA Symposium, 533, 2002.

[58] B. Moszkowski. Reasoning about Digital Circuits. PhD Thesis, Depart-ment of Computer Science, Stanford University, 1983. (Available as tech-nical report STAN–CS–83–970.)

[59] B. Moszkowski. A temporal logic for multilevel reasoning about hard-ware. Computer 18, 2: 10–19, 1985.

[60] B. Moszkowski. Executing Temporal Logic Programs. Cambridge Univer-sity Press, 1986.

[61] M. A. Olson, K. Bostic & M. Seltzer. Berkeley db. In Proceedings of theFREENIX Track: 1999 USENIX Annual Technical Conference, 183–192,1999.

[62] M. A. Orgun & W. W. Wadge. Chronolog: A temporal logic program-ming language and its formal semantics. Department of Computer Science,University of Victoria, Victoria, B.C., Canada, 1988.

[63] M. A. Orgun & W. W. Wadge. Theory and practice of temporal lo-gic programming. In Intensional Logics for Programming, 23–50. OxfordUniversity Press, 1992.

[64] M. A. Orgun & W. Ma. An Overview of Temporal and Modal LogicProgramming. In Temporal Logic, pages 445–479. Springer, 1994.

[65] G. Ozsoyoglu & R.T. Snodgrass. Temporal and real-time databases: Asurvey. In Knowledge and Data Engineering, IEEE Transactions on, 7(4):513–532. IEEE, 1995.

[66] A. Papantonakis & P. H. J. King. Syntax and Semantics of Gql, a Grap-hical Query Language, In Journal of Visual Languages & Computing, 6(1):3–25, 1995.

64

REFERENCIAS REFERENCIAS

[67] R. Pointer, N. Kallen, E. Ceaser & J. Kalucki. Introducing FlockDB.Accesed on July 2011, http://engineering.twitter.com/2010/05/

introducing-flockdb.html

[68] E. Prud’hommeaux & A. Seaborne. SPARQL query language for RDF.Tech. rep., World Wide Web Consortium, 2004. Accessed on July 2011http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/

[69] L. Richardson & S. Ruby. RESTful Web Services. 2007. O’Reilly Media,Inc.

[70] M. A. Rodriguez, J. Shinavier. Exposing Multi-Relational Networks toSingle-Relational Network Analysis Algorithms, Journal of Informetrics,4(1): 29–41. Elsevier, LA-UR-08-03931, 2009.

[71] D. W. Rolston. Chronolog: A pure tense-logic-based in nite-object pro-gramming language. Department of Computer Science and Engineering,Arizona State University, Tempe, Arizona, August 1986.

[72] D. W. Rolston. Chronolog: A pure tense-logic-based in nite-object pro-gramming language. Department of Computer Science and Engineering,Arizona State University, Tempe, Arizona, August 1986.

[73] F. Sadri. Three approaches to temporal reasoning. In A. Galton, editor,Temporal Logics and Their Applications, pages 121–168. Academic Press,1987.

[74] T. Sakuragawa. Temporal Prolog. In Proc. of RIMS Conference on Soft-ware Science and Engineering. Springer-Verlag, 1987.

[75] B. Schneider. Red black trees, In Dr. Dobb’s Journal, 17(4): 42–46. 1992.

[76] P. Smets, A. Mamdani, D. Dubois, & H. Prade, editors. Non-StandardLogics for Automated Reasoning. Academic Press, 1988.

[77] J. F. Sowa. Knowledge representation: logical, philosophical, and compu-tational foundations, 594. MIT Press, 2000.

[78] J. F. Sowa. Conceptual graphs as a universal knowledge representation.In Computers & Mathematics with Applications, 23(2–5): 75–93, 1992.

65

REFERENCIAS REFERENCIAS

[79] M. Stonebraker. SQL databases v. NoSQL databases. In Communica-tions of the ACM, 53(4): 10–11. ACM, 2010.

[80] C. Strauch. NoSQL Databases, Selected Topics on Software-TechnologyUltra-Large Scale Sites. Thesis on Computer Science and Media, StuttgartMedia University, 2011.

[81] J. Tretmans. Model based testing with labelled transition systems. Formalmethods and testing, 1–38, Springer-Verlag, 2008.

[82] A. Tuzhilin & J. Cliford. A temporal relational algebra as a basis fortemporal relational completeness. In D. McLeod, R. Sacks-Davis, & H.Schek, editors, Proceedings of the 16th International Conference on VeryLarge Data Bases, pages 13–23, Brisbane, Australia, August 13–16 1990.Morgan Kaufmann Publishers Inc., Los Altos, California.

[83] M. H. Van Emden & R. A. Kowalski. The semantics of predicate logicas a programming language. In Journal of the ACM (JACM), 23(4): 733–742, 1976.

[84] M. Vardi & P. Wolper. An automata-theoretic approach to automaticprogram verification. In Proceedings of the First Symposium on Logic inComputer Science, 322–331, Cambridge, 1986.

[85] M. Vardi. An automata-theoretic approach to linear temporal logic, 238–266. In Logics for concurrency, Springer, 1996.

[86] W. W. Wadge. Tense logic programming: a respectable alternative. De-partment of Computer Science, University of Victoria, Victoria, B.C., Ca-nada, 1985.

[87] W. W. Wadge. Tense logic programming: a respectable alternative. InProceedings of the 1988 International Symposium on Lucid and Intensio-nal Programming, 26–32, Sidney, B.C., Canada, 1988.

66