You are on page 1of 66

Pyticli: satisfactibilidad de

proposiciones en logica temporal de


intervalos por medio de lenguajes de
consulta sobre grafos.
Javier de la Rosa, versae@gmail.com
M aster en L ogica, Computaci on e Inteligencia Articial
Universidad de Sevilla
26 de agosto de 2011
Resumen
El presente documento es el trabajo nal del Master en Logica,
Computabilidad e Inteligencia Articial impartido por la Universidad
de Sevilla en el curso academico 20102011.
Presenta el lenguaje Pyticli, un sub-lenguaje del lenguaje de pro-
gramacion Python, construido para traducir proposiciones de logica
temporal de intervalos a consultas en lenguajes dise nados para ata-
car bases de datos en grafo. Para ello hace uso del generador interno
de arboles de sintaxis abstrata de Python, a lo que posteriormente
aplica un mecanismo de reduccion para construir una representacion
abstracta de la consulta que pueda ser convertida a cualquier lenguaje
de consulta para bases de datos en grafo.
Keywords Bases de Datos en Grafo, L ogica Temporal, Lenguajes de Con-
sulta.
Director Andres Cord on Franco, acordon@us.es.
1
((Ay, Piticli, bonico, Piticli, ay, Piticli))
1
.
Agradecimientos.
Este trabajo no sera posible sin la paciencia y compresi on del profesorado
del Master en L ogica, Computacion e Inteligencia Articial, que han mostra-
do su caracter m as humano permitiendome no s olo ser evaluado a distancia,
sino adem as componer un jurado para el presente documento aun en periodo
vacacional. En especial quisiera dar las gracias a Andres Cord on, director
del trabajo, por todos sus comentarios y correcciones in extremis; a Joaqun
Borrego por implicarse en que este documento sea posible y adem as este en-
tregado a tiempo; y a Fernando Sancho que siempre ha tenido un hueco para
calmarme y llevarme por el buen camino, y sin el que mi futuro y mi presente
seran bien distintos.
No quiero tampoco olvidar la labor de Juan Luis Suarez, profesor de la
University of Western-Ontario, quien en m as de una ocasi on me ha permitido
usar 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 desde
Espa na, Reino Unido y Canada, quienes parecen tener m as fe en m que yo
mismo. Y por supuesto a mi pareja, Esperanza Ruiz-Pe na, sin cuyo apoyo y
conanza diarias no podra haber aguantado hasta el nal. Gracias.
Como se suele decir, menos da una piedra.
1
Enjuto Mojamuto La Mascota: http://youtu.be/PZORAvBz4k0
2

INDICE

INDICE

Indice
1. Introducci on. 6
1.1. Model Checking. . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Estructura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. L ogica Modal. 9
2.1. L ogica Temporal. . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. L ogica Temporal de Intervalos. 11
3.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Satisfactibilidad. . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Interpretacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Programaci on Logica. 16
4.1. Programaci on en l ogica temporal. . . . . . . . . . . . . . . . . 18
4.1.1. Chronolog. . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2. Templog. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Temporal Prolog de Gabbay. . . . . . . . . . . . . . . . 19
4.1.4. Temporal Prolog de Sakuragawa. . . . . . . . . . . . . 20
4.2. Programaci on en l ogica de intervalos. . . . . . . . . . . . . . . 20
4.2.1. Tempura. . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Tokio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Programaci on en l ogica reicada. . . . . . . . . . . . . . . . . 22
4.3.1. Temporal Prolog de Hrycej. . . . . . . . . . . . . . . . 22
4.3.2. Starlog. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Representaci on del conocimiento. 24
5.1. Sistemas de transicion etiquetados. . . . . . . . . . . . . . . . 24
5.2. Estructuras de Kripke. . . . . . . . . . . . . . . . . . . . . . . 25
5.3. Consideraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Bases de Datos en Grafo. 28
6.1. Bases de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. DEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. FlockDB. . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.3. HyperGraphDB. . . . . . . . . . . . . . . . . . . . . . 30
3

INDICE

INDICE
6.1.4. InfoGrid. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.5. InniteGraph. . . . . . . . . . . . . . . . . . . . . . . . 32
6.1.6. Neo4j. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.7. OrientDB. . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2. Lenguajes de consulta. . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1. GQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.2. GraphLog. . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.3. Gremlin. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.4. PQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.5. SPARQL. . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.6. UnQL/UnCAL. . . . . . . . . . . . . . . . . . . . . . . 36
7. L ogica temporal de intervalos y consulta de grafos. 37
7.1. Estructuras de Kripke sobre bases de datos grafo. . . . . . . . 37
7.2. L ogica temporal sobre lenguaje de consultas para grafos. . . . 38
7.2.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.2. Satisfactibilidad. . . . . . . . . . . . . . . . . . . . . . 39
7.2.3. Interpretacion. . . . . . . . . . . . . . . . . . . . . . . 41
8. Lenguaje Pyticli. 43
8.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2. Limitaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3. Algoritmo de conversi on. . . . . . . . . . . . . . . . . . . . . . 46
8.4. Aplicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4.1. Operadores b asicos. . . . . . . . . . . . . . . . . . . . . 51
8.4.2. Operadores compuestos. . . . . . . . . . . . . . . . . . 52
8.5. Mejoras al lenguaje. . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.1. Operadores y . . . . . . . . . . . . . . . . . . . . . 53
8.5.2. Operadores temporales. . . . . . . . . . . . . . . . . . . 53
8.5.3. Lenguajes de salida. . . . . . . . . . . . . . . . . . . . 53
8.6. Consola interactiva. . . . . . . . . . . . . . . . . . . . . . . . . 55
9. Conclusiones y trabajo futuro. 58
10.Bibliografa. 59
4

INDICE DE FIGURAS LIST OF ALGORITHMS

Indice de guras
1. Grafo de estados con varios caminos posibles. . . . . . . . . . 40
2. Grafo de estados simple. . . . . . . . . . . . . . . . . . . . . . 40
List of Algorithms
1. Algoritmo general de conversi on: Pyticli . . . . . . . . . . . 47
2. Algoritmo de procesado del AST: ProcessTree . . . . . . . . 48
3. Algoritmo de reducci on de pila: StackReduce . . . . . . . . . 50
5
1 INTRODUCCI

ON.
1. Introducci on.
Este trabajo presenta las analogas entre la l ogica modal proposicional
temporal (en adelante l ogica temporal) y el dominio de la teora de grafos.
Los actuales lenguajes temporales, basados en el correpondiente sustrato
te orico, est an ideados para generar estructuras y conjuntos de estados que
satisfagan proposiciones dadas, de manera que se pueda denir y caracterizar
un determinado sistema (formalmente, modelo) a partir del comportamien-
to esperado de este a lo largo del tiempo. Esto es especialmente util en la
denici on de modelos concurrentes. Recientemente, la Association for Com-
puting Machinery (ACM) concedio el Premio Turing a los creadores de un
mecanismo autom atico de vericaci on de estos modelos
2
, tecnica que recibe
el nombre de model checking.
La aproximaci on que aqu se presenta est a a camino entre el model checking
y los lenguajes temporales. La nalidad ultima de este trabajo es proporcio-
nar un marco practico sobre el cual poder vericar proposiciones especcas
de un sistema seg un su comportamiento. Para ello suponemos que cada vez
que el sistema cambia de un estado a otro, una traza conteniendo los valores
de cada variable es almacenada en una base de datos en grafo, de manera que
se establezca una arista dirigida entre cada dos estados si desde un estado
i
se ha pasado a otro
j
. El utilizar bases de datos en grafo para almacenar
esta informaci on es crucial ya que de esta manera se proporciona no solo un
metodo de almacenamiento ecaz, robusto, masivo y colaborativo, sino un
mecanismo para realizar consultas sobre los datos a traves de los lenguajes
nativos que implementan. Proponemos, en este sentido, un lenguaje capaz de
traducir proposiciones de l ogica temporal a consultas sobre bases de datos en
grafo, eliminando la complejidad inherente de la tecnica de model checking.
2
Researchers 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 INTRODUCCI

ON.
1.1. Model Checking.
Si denimos el proceso mediante el cual, dado un sistema de estados, es ne-
cesario averiguar si un cierto conjunto de proposiciones se verica, tendramos
lo que se conoce como model checking [20]. Esta tecnica se emplea tanto en
sistemas hardware como software, y ha demostrado ser especialmente util en
comparaci on con otras como la simulaci on o el razonamiento, en sistemas
paralelos 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 de
espacio fsico de almacenamiento. A traves del -C alculo y una l ogica tem-
poral especca (CTL) es capaz de manipular formulas y relaciones y decidir
sobre la satisfactibilidad de f ormulas expresdas en l ogica temporal lineal, evi-
tando as el problema conocido como explosion de estados se conoce como
explosion de estados al incremento exponencial de estados que se da al inten-
tar vericar un sistema concurrente. Este problema releg o en un principio la
vericaci on automatica a sistemas peque nos y fue el origen del model chec-
king; pero con la aparici on de los nuevos sistemas de bases de datos en grafo,
capaces de escalar ecientemente, la cantidad maxima de estados posibles en
un sistema se incrementa de nuevo, pudiendo ahora esta tecnica ser aplicada
en maquinas de caractersticas sencillas y asequibles.
A posteriori, el algoritmo de conversi on de proposiciones de logica temporal
a consultas sobre grafos ha resultado tener ciertas similitudes al empleado en
model checking para -C alculo, incluso sin haber sido inspirado en el.
1.2. Estructura.
Tras una primera presentaci on de las l ogicas modales y un posterior anali-
sis y denici on de las logicas temporales, se muestran algunas de las distintas
implementaciones que se han ido desarrollando a lo largo del tiempo, pasan-
do desde las basadas exclusivamente en Prolog o Lisp [7, 8] hasta lenguajes
completos 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 programaci on lineal y los sistemas deductivos
7
1.2 Estructura. 1 INTRODUCCI

ON.
e inductivos. El estudio se centra especcamente en los Sistemas de Tran-
sici on Etiquetados, usados en la logica temporal basada en acciones, y las
estructuras de Kripke, que sustentan la l ogica temporal basada en estados.
Ambas construcciones son, como veremos, formas particulares de grafos.
Un apartado dedicado a la denicion de las bases de datos basadas en
grafo, que vienen a integrar el grupo de las recien nombradas NoSQL (que
conviene no confundir con el gestor de bases de datos de identico nombre [51])
tambien es presentado. Tras numerar algunas de las m as conocidas de estas
bases de datos, se introducen a continuaci on los lenguajes sobre los que se
construyen las consultas y que resultan indispensables en cualquier base de
datos.
Por ultimo discutiremos c omo esta aproximaci on 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 ecientemente
en disco. Los ultimos apartados se dejan para las conclusiones y el posterior
trabajo futuro.
8
2 L

OGICA MODAL.
2. Logica Modal.
Las l ogicas modales forman parte de las logicas formales y amplan su
dominio para incluir el estudio de propiedades dependientes del contexto
modalidad tales como necesidad y posibilidad [10, 11]. Para ello hacen uso
de dos nuevos smbolos que a naden a los ya existentes en el vocabulario de la
l ogica proposicional a la que extienden, estos son para denotar necesidad,
es necesario que; y para posibilidad, es posible que. Quedando adem as
denidos cada uno en funcion del otro como se muestra en (1 , 2).
p = q (1)
p = q (2)
Existe pues una clara analoga con los cuanticadores en la l ogica de
primer orden, donde se tiene (3, 4).
x (x) = x(x) (3)
x (x) = x(x) (4)
La regla de inferencia m as habitual en la logica modal es la necesita-
cion (5), y junto al modus ponens de la logica proposicional permiten denir
distintos tipos de sistema.


(5)
Cada sistema est a basado en unos axiomas y dependiendo de cuales y
cu antos utilice sera posible demostrar un mayor o menor n umero de teo-
remas. As, partiendo del axioma m as basico, denominado K (6) en honor
a Samuel Kripke [45], podemos a nadir distintos axiomas obteniendo cada
vez un sistema distinto sobre el que aplicar una interpretacion. Los axiomas
de K tambien incluyen todas las instancias de las tautologas de la l ogica
proposicional.
( ) ( ) (6)
(7)
De manera que las reglas para una K-prueba son:
9
2.1 Logica Temporal. 2 L

OGICA MODAL.
Modus ponens. Dados y = , se tiene .
Sustitucion (uniforme). Dado se tiene , donde se obtiene a partir
de reemplazando uniformemente los atomos de la proposicion en
por f ormulas arbitrarias.
Generalizacion. Dado , se tiene .
Si denimos como estructura relacional la tupla 'W, R
1
, . . . , R
k
` tal que W
es un conjunto no vaco y cada R
i
es una relacion sobre W, podemos denir
una interpretaci on o modelo como la tupla = 'F, v`, donde:
T es un marco denido por la tupla 'W, R` y donde:
W es un conjunto no vaco de elementos que reciben el nombre de
mundos posibles.
R es una relaci on entre los mundos posibles denominada relacion
de accesibilidad. La relacion de accesibilidad puede ser reexiva,
transitiva, eucldea y/o simetrica, lo que permite obtener los dis-
tintos tipos de sistemas.
v es un asignaci on en un marco T = 'W, R` y viene dada por la fun-
ci on que asocia a cada smbolo proposicional el subconjunto de mundos
donde es verdadera.
2.1. Logica Temporal.
La logica temporal [14, 72] puede verse como una instancia de la logica
modal en la que el conjunto de mundos posibles representa una colecci on
de instantes o momentos en el tiempo [64]. A nade dos nuevos operadores
existenciales a la l ogica modal proposicional, cuyas lecturas son [29]:
'P`, se satisface en alg un momento del pasado (Past).
'F`, se satisface en alg un momento del futuro (Futuro).
Tambien son habituales los correspondientes duales, que tienen car acter 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 L

OGICA TEMPORAL DE INTERVALOS.


[G] = 'F`, siempre va a ser (Going to be) satisfecha en el
futuro. Es decir, no existe un momento en el futuro en que no se vaya
a satisfacer.
A partir de estos operadores que suelen escribirse simplemente como P,
F, H y G se pueden construir sistemas m as o menos especcos seg un las
restricciones que se incluyan sobre las relaciones. As, un marco adecuado
para la logica temporal b asica podra incluir dos relaciones binarias [29], R
P
y R
F
, que facilitasen las deniciones de transitividad y reciprocidad (logica
modal normal ) P GP para expresar que ((lo que sea que haya ocurrido
siempre ha ocurrido)) [10]; una noci on de tiempo denso estableciendo con
F FF que entre cualesquiera dos instantes siempre hay un tercero [10];
o la conocida como formula de McKinsey [56], GF FG, algo as como
un reejo de la nocion termodinamica de la distribucion de la informaci on.
3. Logica Temporal de Intervalos.
La Logica Temporal de Intervalos o ITL [58, 37, 59] fue propuesta por
primera vez por Ben Moszkowski. A lo largo de esta secci on seguiremos las
directrices y nomenclaturas usadas por Moszkowski en [60], donde propone el
uso de dos nuevos smbolos l ogicos, (siguiente) y (siempre), y a los que
a nade los operadores = (igualdad) y (conjunci on). Sin embargo, aunque
el resto de operadores l ogicos puede deducirse a partir de los anteriores,
nosotros daremos tambien por validas todas las conectivas propias de la l ogica
proposicional.
3.1. Sintaxis.
Para construir expresiones usaremos lo siguiente:
Variables individuales: A, B, . . .
Funciones: f(e
1
, . . . , e
k
), donde k 0 y cada e
i
es una expresi on. Su-
ponemos predenidas funciones aritmeticas b asicas como + o mod,
adem as de las constantes 0 y 1.
Operador siguiente: e, donde e es una expresi on.
Por su parte, las formulas se construir an como sigue:
11
3.2 Modelos. 3 L

OGICA TEMPORAL DE INTERVALOS.


Predicados: p(e
1
, . . . , e
k
), donde k 0 y cada e
i
es una expresi on. En
este caso tambien suponemos denidas relaciones como .
Igualdad: e
1
= e
2
, donde cada e
i
es una expresi on.
Conectivas l ogicas: w
1
y w
2
w
3
, donde cada w
i
es una f ormula.
Operador ((siguiente)) (next): w, donde w es una f ormula.
Operador ((siempre)) (always): w, donde w es una f ormula.
3.2. Modelos.
En ITL, un modelo es una tripleta 'T, , ` donde T es el dominio de
los datos, el conjunto de estados, y una interpretaci on que dota de
signicado a cada smbolo de predicado y funcion. Un estado es una funci on
que mapea variables a valores de un dominio, as, podemos tener un estado
s de T en el que la variable A tenga el valor 5, lo que denotaremos por
sA = 5. Cada smbolo de funci on f tiene una interpretacion f que
mapea k elementos en T a un solo valor (8).
f (D
k
D) (8)
Para el caso de las proposiciones, que deben ser evaluadas como ciertas o
falsas, usaremos true y false (9).
f (D
k
true, false) (9)
Dado , denimos I =
+
como el conjunto de todas las secuencias nitas y
no vacas de estados. La longitud de un intervalo I vendr a dada por [[
y se correspondera con el n umero de estados en el intervalo menos uno, de
manera que cada intervalo estara compuestos de al menos un estado
i
(10).
= '
0
,
1
, . . . ,
||
` (10)
3.3. Satisfactibilidad.
Decimos que una f ormula w es satisfecha en un intervalo , o que el
intervalo satisface la f ormula w si y s olo si el signicado de w en es igual
a true (11), lo que puede denotarse de forma abreviada (12).

w = true (11)
12
3.4 Interpretaci on. 3 L

OGICA TEMPORAL DE INTERVALOS.


[= w (12)
Si todos los intervalos satisfacen w, entonces decimos que w es valida (13).
[= w (13)
3.4. Interpretaci on.
Para dar signicado a expresiones y formulas sobre intervalos, denimos

e como el valor en T de la expresi on e en el intervalo . Analogamente,

w ser a el resultado l ogico (true o false) de la formula w en . Puede


a veces encontrarse esta notaci on de forma abreviada eliminando la notacion
de modelo (14)

e e

(14)

w w

(15)
El listado de deniciones es el que sigue:

V =
0
V , donde V es una variable. Es decir, el valor de una
variable en un intervalo es igual a su valor en el estado inicial del
intervalo.

f(e
1
, . . . , e
k
) =

f(

e
1
, . . . ,

e
k
), de manera de que
la interpretacion del smbolo de funcion f se aplica a las interpretacio-
nes de e
1
, . . . , e
k
.

p(e
1
, . . . , e
k
) =

p(

e
1
, . . . ,

e
k
) . De forma similar
a la denici on anterior.

e
i
= e
j
= true

e
i
=

e
j

w = true

w = false

w
i
w
j
= true (

e
i
= true) (

e
j
= true)

e =

1
,...,
||

e, si se tiene que [[ 1. El valor de e se


deja sin especicar sobre intervalos de longitud 0.

w = true, en el caso en que [[ 1 y adem as

1
,...,
||

w =
true.
13
3.4 Interpretaci on. 3 L

OGICA TEMPORAL DE INTERVALOS.

w = true i [[ :

i
,...,
||

w = true.
A partir de aqu podemos derivar otros tantos operadores secundarios que
se apoyen en las deniciones anteriores pero que faciliten un poco la creaci on
de proposiciones m as ricas.

w = true i [[ :

i
,...,
||

w = true. Este es el
operador ((a veces)) (sometimes) y es el dual de always, ya que w
puede ser denido como w.

len(e) = true

e = [[. Conocido como el operador lon-


gitud, permite comprobar si la longitud de un intervalo es igual a la
expresi on e.
w
i
w
j
sera equivalente a (w
i
w
j
)
w
i
w
j
, la implicaci on vendra dada por w
i
w
j
if b thenw
i
else w
j
. La construccion del condicional se hace utilizando
el operador de implicaci on, (b w
i
) (b w
j
).
w
i
w
j
se obtendra a partir de (w
i
w
j
) (w
j
w
i
)
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 a
empty, [= more empty.
e
i
gets e
j
(more [(e
i
) = e
j
]), lo que vendra a ser lo mismo que
k[[ :
k+1
e
i
= e
j
. Es decir, se cumple en todos los estados que el
siguiente a e
i
es siempre e
j
. Podramos hacer una lectura aproximada
interpretando gets como ((llega a ser)), o ((se convierte en)).
stable e e gets e, para expresiones que no varan con el paso del tiem-
po.
halt w tendra una denicion equivalente a (w empty), es decir,
comprueba si w se eval ua a false en todos los estados salvo el ultimo,
donde debera ser cierta para que halt w = true.
e
i
e
j
, se conoce como igualdad temporal es cierta si y solo si (e
i
=
e
j
).
14
3.4 Interpretaci on. 3 L

OGICA TEMPORAL DE INTERVALOS.


w (w. Es el operador weak next cuya denicion 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 tiene
longitud 0.
finw, denido como (empty w), permite establecer condiciones a
satisfacer en el ultima estado de un intervalo, independientemete de lo
que ocurra en el resto (versi on debil de halt).
e
i
e
j
, conocido como asignaci on temporal, es equivalente a decir
que a : [(a = e
i
) (fin(e
j
) = a)]. Su comportamtiento es, por tanto,
vericar que el valor de e
j
en el estado nal
||
es el mismo que el de
e
i
en el estado inicial
0
. Podramos decir que es una forma de post-
condici on que busca ser vericada si la relaci on entre e
i
y e
j
se mantiene
constante entre los estados inicial y nal.
skip w toma valor true en intervalos que tienen un unico estado (lon-
gitud 1), por lo que puede expresarse como empty.
Adem as de estos, otros operadores pueden ser denidos para facilitar la crea-
ci on de proposiciones expresadas en ITL, sin embargo no ser an tenidos en
cuenta al estar basados en el operador chop de composici on secuencial que no
deniremos formalmente. El operador chop puede ser usado para la deni-
ci on de nuevos operadores como las versiones inversas y acotadas de always
y sometimes, bucles e iteradores. En realidad a partir de chop se pueden
denir 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. La
sintaxis habitual de chop suele ser el smbolo ;, de manera que la expresi on
w
i
; w
j
es cierta si y s olo si puede ser dividida en dos subintervalos,
i
y
m
,
y w
i
se satisface en
l
mientras que w
j
lo hace en
m
. Este operador puede
extenderse por composicion, chop, para dividir en tantos subintervalos
como sean precisos.
15
4 PROGRAMACI

ON L

OGICA.
4. Programaci on L ogica.
La sem antica de los programas logicos fue desarrollada por Van Emden y
Kowalski [83] y, seg un este ultimo, deben seguir una meta clara [44] respecto
a los problemas que se pretenten resolver: ((Los programas logicos deberan
especicar que va a ser computado; no como va a ser computado)). Es decir,
mientras que en la programaci on algortmica, la de lenguajes como C o Java,
el control de la ejecuci on va ligado a las instrucciones que resuelven el pro-
blema, en la programacion declarativa en la que se incluye la programaci on
l ogica s olo se deberan especicar el conocimiento y las asunciones que sobre
un problema especco se tiene. Lo que se consigue por medio de las llama-
das cl ausulas de Horn (clausulas con un literal positivo como m aximo). Estas
cl ausulas constituyen el sistema de axiomas que componen un programa l ogi-
co, de manera que la prueba de satisfactibilidad del conjunto de clausulas se
corresponda con la ejecuci on del programa.
Denotamos como clausula de Horn la expresi on A B
1
, . . . , B
n
y, en su
forma clausulada, (B
1
. . . B
n
) A = B
1
. . . B
n
A, donde solo
hay, como m aximo, un literal positivo A al que se denomina cabeza, mientras
que al resto de literales B
i
se les denomina cuerpo. De esta manera podemos
hacer una lectura aproximada diciendo que si cada B
i
es una formula cierta,
entonces A tambien lo es.
Las clausulas de Horn se clasican en dos tipos:
Clausula objetivo u objetivo, aquella que no tiene literales positivos,
B
1
. . . B
n
, donde cada B
i
es un sub-objetivo.
Clausula de programa, aquella que tiene al menos un literal negativo y
un unico literal positivo. Si la cl ausula de programa s olo consta de un
literal positivo A, se la llama clausula unitaria o hecho y se interpreta
que A es una formula cierta para cada asignacion de cada variable. Al
conjunto de hechos basicos se le suele denominar base de datos.
De esta manera podemos denir el programa l ogico como un conjunto de
predicados, donde cada uno es a su vez un conjunto de cl ausulas de Horn que
comparten el literal en sus cabezas.
16
4 PROGRAMACI

ON L

OGICA.
La importancia de las cl ausulas de Horn y el motivo por el cual son el me-
canismo sobre el que se construyeron lenguajes como Prolog, es la existencia
del metodo de resolucion lineal selectiva con cl ausulas denidas o SLD [43],
un metodo adecuado y completo cuando se aplica en sistemas de clausulas
de Horn. B asicamente el metodo consiste en aplicar derivaciones entre las
cl ausulas del programa P y la cl ausula objetivo G, de manera que una re-
futaci on de SLD sobre P G es una derivacion SLD nita de P G que
tiene la clausula vaca como ultimo objetivo en la derivaci on. El metodo se
desarrolla por recursi on mediante sustituci on por unicaci on. En realidad se
dene implcitamente un arbol de b usqueda de las computaciones alternati-
vas aplicando razonamiento con vuelta atras, de forma que la raz del arbol
se asocia con la cl ausula meta incial y en el que cada nodo hoja es un nodo
satisfactorio si su cl ausula objetivo asociada es la cl ausula vaca. Si la cl ausu-
la asociada a un nodo hoja no es vaca pero su literal asociado ya no puede
unicarse con ninguna cl ausula de entrada, entonces se dice que el nodo es
un fallo.
Si bien la programaci on logica se aplica en un creciente n umero de pro-
blemas pertenecientes a muy diversos dominios, tambien adolece de ciertas
limitaciones. Es el caso de los problemas que requieren una nocion de cambio
din amico en el tiempo. A veces se ha intentado extender la programaci on
l ogica con anotaciones, sistemas de predicados a nadidos y otros mecanismos,
y aunque estas son sin duda grandes contribuciones al mundo de la programa-
ci on, terminan por difuminar el caracter l ogico de los programas. La solucion
no pasa por a nadir caractersticas no l ogicas a la programaci on logica, sino
en desarrollar mejores y m as potentes herramientas como las logicas modales
o temporales.
En este sentido se presentan las l ogicas temporales, ya que representan
la mejor manera de extender la programacion l ogica para modelar propie-
dades din amicas dependientes del tiempo como las usadas en razonamiento
temporal o simulacion. Existen propuestas para extender la programacion
l ogica con l ogica temporal e incluso implementaciones operativas con algu-
nas restricciones con respecto al desarrollo te orico. Una buena parte de estas
implementaciones de lenguajes temporales han sido construidas sobre Prolog,
ya sea con modicationes en el algoritmo de unicaci on interno SLD o con
reglas extra para los operadores temporales.
17
4.1 Programaci on en l ogica temporal. 4 PROGRAMACI

ON L

OGICA.
4.1. Programaci on en logica temporal.
Las siguientes implementaciones estan basadas en los conceptos m as sim-
ples de la logica temporal b asica lineal y de ramicacion explicados en la
secci on 2.1, extendiendolos seg un las necesidades de cada lenguaje.
4.1.1. Chronolog.
Chronolog fue concebido por Wedge [86, 87] como propuesta sobre la
programaci on logica basada en cl ausulas de Horn antes de su materializaci on
denitiva como lenguaje [62, 63, 72]. Utiliza el conjunto de los naturales como
la colecci on de momentos en el tiempo y consta de dos operadores temporales:
rst, para referirse al momento inicial en el tiempo.
next, usado para el momento siguiente.
Esta concepci on implica una noci on de movimiento a traves del eje temporal.
4.1.2. Templog.
Originalmente propuesto por Abadi y Mann [1, 2], Templog utiliza un eje
temporal lineal y discreto con un futuro sin acotar basado en el conjunto de
los n umeros naturales. Templog tiene la misma sintaxis que Prolog excepto
por los tres operadores temporales que introduce:
, el siguiente momento en el tiempo.
, a partir de ahora.
, alguna vez en el futuro.
Surgen as algunos conceptos nuevos:
next-atom, atomos con un prejo de operadores next. Se denota por

k
A, donde A es un atomo y
k
es una k-aplicaci on 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 , cl ausula de la forma B A
1
, . . . , A
n
donde cada B y
cada A
i
son next-formulas.
18
4.1 Programaci on en l ogica temporal. 4 PROGRAMACI

ON L

OGICA.
clausula permanente, an alogamente, clausula de la forma B A
1
, . . . , A
n
donde cada B y cada A
i
son next-formulas. La diferencia con la clausula
inicial es el car acter temporal, ya que la clausula permanente implica
al operador .
Podemos denir ahora un programa en Templog como una conjunci on de
cl ausulas iniciales y permanentes, siendo el objetivo una conjunci on de next-
formulas. Su procedimiento de resolucion, llamado TSLD , tiene un n umero
de 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 llamado
TL1 en el que el unico operador temporal es .
Si bien puede demostrarse que tanto Chronolog como Templog tienen el
mismo poder expresivo simplemente sustituyendo el operador por next y
aplicando rst a todas las clausulas iniciales de Templog, el resultado no
tiene mayor trascendencia que el meramente te orico.
4.1.3. Temporal Prolog de Gabbay.
En [31] Gabbay propuso una extensi on de Prolog, a la que llam o conve-
nientemente Temporal Prolog, que haca posible el uso de conectivas tempo-
rales y modales en la programaci on l ogica. Estas conectivas fueron en prin-
cipio P, para expresar alguna vez en el pasado, F, para alguna vez en el
futuro, y para la nocion de siempre. Aunque el lenguaje es muy expresivo
e incluso permite implicaciones anidadas, no puede usarse en las cl ausulas
de 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 cl ausula siempre.
clausula siempre, denida como A donde A es una cl ausula ordinaria.
clausula ordinaria, que puede tener solo una cabeza o una cl ausula del
tipo A H donde A es el cuerpo y H la cabeza.
cabeza, siendo esta una f ormula at omica o una construcci on de la forma
FA o PA, donde A es una conjunci on de clausulas ordinarias.
cuerpo, denido como una f ormula atomica, una conjunci on de cuerpos,
o una f ormula del tipo FA o PA donde A es un cuerpo.
19
4.2 Programaci on en l ogica de intervalos.4 PROGRAMACI

ON L

OGICA.
La admisi on de los operadores F y P en la cabeza de una cl ausula de progra-
ma provocan, de acuerdo a Orgun y Wadge [63], que esta extensi on de Prolog
no cumpla con la sem antica de modelo mnima. Aunque existen conjeturas
que apuntan en la direcci on 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 extensi on respecto a
las dem as es que Sakuragawa consider o en su lenguaje que todas las clausulas
de pograma son causales, esto es, el signicado de los predicados en el futuro
depende de su signicado en el pasado. Los operadores temporales relativos
a tiempos pasados como (momento previo en el tiempo) pueden darse en
la cabeza de una cl ausula, lo que provoca que programas escritos en esta
versi on de Temporal Prolog no sean traducibles directamente a otros como
el de Gabbay, Templog o Chronolog.
4.2. Programaci on en logica de intervalos.
Como se describe en la secci on 3, la l ogica temporal de intervalos es una
forma de logica temporal en la cual la semantica de las formulas se dene por
medio de interpretaciones temporales y pares, es decir, pares de momentos
en el tiempo que representan una duracion especca. Los dos lenguajes mas
representativos de este tipo de l ogica son Tempura [60, 35] y Tokio [4], ambos
considerados lenguajes para programaci on temporal en un sentido amplio.
Este tipo de lenguajes, aunque pueden usar los mecanismos en su ejecu-
ci on, no est a basado en el paradigma habitual de la programaci on l ogica de
resoluci on y unicaci on. Incluso incluyen algunas caractersticas heredadas
de los lenguajes funcionales.
4.2.1. Tempura.
El lenguaje Tempura, propuesto por Moszkowski [60], ha llevado un desa-
rrollo paralelo a la l ogica temporal de intervalos a la que se debe, aunque su
implementaci on mantiene una noci on discreta del tiempo. No es de extra nar,
por tanto, que todos los operadores y sintaxis de la ITL tengan cabida en
el lenguaje con una traduccion casi inmediata. Los operadores basicos de
20
4.2 Programaci on en l ogica de intervalos.4 PROGRAMACI

ON L

OGICA.
Tempura son (always) y (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, un
programa Tempura es un conjunto de formulas ejecutables, aunque tambien
existe un conjunto de operadores secundarios, denidos sobre los anteriores,
para facilitar la tarea del programador y hacer el lenguaje m as asequible.
Otra decision de dise no importante es la de eliminar la disyunci on y la
negaci on en aras de la eciencia.
Las ejecuciones de los programas escritos para Tempura consisten en pro-
cesos de reduccion, debido a que en cada ejecuci on el programa se reduce
conforme a las operaciones en los intervalos de tiempo, y se repite el proceso
sucesivamente hasta que el subintervalo actual a evaluar s olo consta de un
estado, esto es, el intervalo no puede volver a ser dividido.
4.2.2. Tokio.
Tambien basado en la ITL e inuenciado por Tempura, se presenta el
lenguaje Tokio para descripci on de componentes hardware propuesto por
Aoyagi, Fujita, and Moto-oka [4].
Los operadores principales de Tokio son:
concurrency(, ), la clausula P :- Q, R signica 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 cl ausula P :- Q && R signica que Q ser a ejecutado al
principio del primer subintervalo y R al principio del segundo.
next(@), la cl ausula P :- @Q signica que Q ser a ejecutado en el inter-
valo de tiempo inmediatamente posterior al actual.
always(#), la cl ausula P :- #Q signica que Q se ejecutara en todos
los subintervalos que componen el intervalo de P.
sometime <>, la clausula P :- <>Q signica que Q ser a ejecutado en
alg un momento en el intervalo en que P es ejecutado.
21
4.3 Programaci on en l ogica reicada. 4 PROGRAMACI

ON L

OGICA.
keep, la cl ausula P :- keep(Q) signica que Q ser a ejecutado en cada
subintervalo de P excepto en el nal.
final(fin), la cl ausula P :- fin(Q) signica que Q s olo ser a ejecutado
en el intervalo nal de P.
Los intervalos pueden ser manipulados usando determinados operadores de-
nidos en el lenguaje como length, empty y notEmpty. La ejecuci on de un
programa Tokio es una mezcla de resoluci on y reduccion. En lo relativo a la
unicaci on de variables, al igual que en Tempura, estas pueden variar con
el tiempo, por lo que el proceso de unicacion es complicado y se divide en
dos tipos: uno para unicar dos valores de variables Tokio, y el otro usando
directivas especiales para unicacion de variables en momentos especcos.
4.3. Programaci on en logica reicada.
Con la nalidad de completar un cat alogo b asico de opciones en progra-
maci on logica, incluimos tambien dos implementaciones no basadas en los
conceptos clasicos de la l ogica temporal, de intervalos o no.
4.3.1. Temporal Prolog de Hrycej.
Hrycej tambien desarroll o una extension a la que llam o Temporal Pro-
log [40], aunque en esta ocasi on no estaba basada directamente en logica
temporal, sino que implementa la sem antica de la l ogica temporal en Prolog,
siendo capaz de manejar sentencias l ogicas referenciadas temporalmente y
restricciones temporales.
Al igual que las anteriores Temporal Prolog, tambien est a construido sobre
Prolog introduciendo en este caso dos tipos adicionales de cl ausulas:
Referencias temporales, usadas para armar que se tiene una cierta
sentencia exactamente durante un intervalo de tiempo.
Restricciones temporales, que permiten crear axiomas para las relacio-
nes entre los intervalos de tiempo.
El propio Hrycej se nal o en [40] como aplicacion de su extensi on la planica-
ci on y consulta de bases de datos, as como la potencial aplicaci on en fsica
cualitava [41].
22
4.3 Programaci on en l ogica reicada. 4 PROGRAMACI

ON L

OGICA.
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 igual
que el anterior, tampoco esta basado directamente en la logica temporal,
de hecho, siquiera proporciona operadores temporales, sino que simplemente
a nade un argumento adicional a cada predicado de Prolog [21].
23
5 REPRESENTACI

ON DEL CONOCIMIENTO.
5. Representaci on del conocimiento.
Sowa deende que, dado un dominio, la tarea de construir sobre el modelos
computables usando para ello la logica y las ontologas es lo que conocemos
como representacion del conocimiento [77]. Insiste en la importancia de es-
tablecer relaciones entre el conocimiento del mundo real y modelos capaces
de ser computados. Tanto es as que lleg o a proponer un tipo especial de
grafos, a los que llam o grafos conceptuales, como la representaci on universal
del conocimiento [78].
Valga esta mencion para ilustrar la importancia, la relevancia y la ade-
cuaci on de los grafos para la representacion del conocimiento, lo que es una
aproximaci on habitual en Inteligencia Articial [17]. En nuestro caso, sin em-
bargo, las bases de conocimiento que se suelen manejar en la programaci on
l ogica son, por as decirlo, mas planas. A modo de ejemplo, las bases de co-
nocimiento en Prolog no son m as que sucesiones de hechos que se dan por
v alidos escritos, en principio, sin ninguna relaci on sem antica entre ellos.
No obstante, cuando se trata de l ogicas temporales la situaci on vara un
poco, ya que es necesario expresar la nocion de temporalidad, algo que
com unmente se ha venido haciendo representando los estados
i
del inter-
alo como nodos de un grafo cuyas aristas denotan no solo el paso de un
estado a otro, sino el transcurso del tiempo. Veremos a continuacion dos de
las construcciones m as habituales para almacenar la din amicas temporales
sobre las que posteriormente podremos vericar proposiciones.
5.1. Sistemas de transici on etiquetados.
Un sistema de transicion etiquetado (LTS de sus siglas en ingles) es b asi-
camente un grafo dirigido con etiquetas en las aristas, donde los estados
equivalen a los vertices y las transiciones etiquetadas a las aristas con eti-
quetas. Se utilizan a menudo para denir el comportamiento de un proceso
que cambia en el tiempo. Los estados modelan los estados del sistema y las
transiciones etiquetadas modelan las acciones llevadas a cabo por el sistema.
24
5.2 Estructuras de Kripke. 5 REPRESENTACI

ON DEL CONOCIMIENTO.
Un sistema de transici on etiquetado sobre el conjunto de acciones / y el
de predicados {, es una tripleta 'S, , [=` donde [81]:
S es un conjunto no vaco y numerable de estados.
es una colecci on de relaciones binarias (transiciones)
a
SS una
para cada a /, tales que s S, t S[s
a
t es un conjunto.
[= S {, de forma que s [= p signidica que el predicado p P se da
en el estado s S.
Informalmente, una transicion se da cuando el sistema se encuentra en un
estado s
i
que puede efectuar la acci on a
l
y entonces va al estado s
j
. Lo
denotamos por s
i
a
l
s
j
, es decir, hay una transici on etiquetada por a desde
el estado s
i
al estado s
j
. Si, ademas, desde el estado s
j
existe una transicion
etiquetada con a
m
tal que s
j
am
s
k
, entonces se puede componer la notaci on
y escribir s
i
a
l
s
j
am
s
k
, o lo que es lo mismo, s
i
a
l
a
k
s
k
. En general, la
composici on de transiciones se puede expresar como s
1
a
1
a
2
...an
s
2
.
Conviene resaltar la importancia del no determinismo de los sistemas de
transici on 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 transicion
etiquetado donde el conjunto de transiciones solo consta de una relacion
binaria simple sobre S. Este tipo de estructuras de Kripke son las usadas
en logica modal y, por tanto, en l ogica temporal. Aunque no son las unicas
que existen. Si por ejemplo permitimos que / sea un conjunto arbitrario de
acciones tendramos estructuras de Kripke para l ogica polimodal.
Formalmente, denimos una estructura de Kripke sobre los conjuntos /
y { 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 REPRESENTACI

ON DEL CONOCIMIENTO.
T S S es una relaci on de transici on entre estados.
l : S {(/) es la funcion de etiquetado de estados que asigna a cada
estado un proposici on de /.
Las estructuras de Kripke pueden usarse para modelar la sem antica de la
l ogica, 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 estado
tenga 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 innita
de estados = 's
1
, s
2
, . . .`, denimos (i) = s
i
y = (s
i
, s
i+1
, . . .)i N.
Una secuencia innita de estados es un camino si (i) (i + 1) i N.
Decimos que la f ormula f es v alida a lo largo de , denotado como [= f, si
para el camino en la estructura de Kripke M podemos decir:
[= p si y s olo si p l((0))
[= p si y s olo si p / l((0))
[= f g si y s olo si [= f y [= g
[= f g si y s olo si [= f o [= g
[= Gf si y s olo si i,
i
[= f
[= Ff si y s olo si i,
i
[= f
[= Xf si y s olo si
1
[= f
[= fUg si y s olo si i[
i
[= g y j < i,
j
[= f]
[= fRg si y s olo si i[
i
[= g o j < i,
j
[= f]
De esta manera, una formula f es universalmente valida en una estructura
de Kripke M, y denotamos M [= Af, si y s olo si [= f M, (0) I.
Por otra parte, es existencialmente valida, M [= Ef, si y s olo si [= f
M, (0) I
26
5.3 Consideraciones. 5 REPRESENTACI

ON DEL CONOCIMIENTO.
5.3. Consideraciones.
Aunque como hemos visto las estructuras de Kripke son una forma de
sistema de transici on etiquetado, De Nicola y Vaandrager [25] desarrollaron la
l ogica ACTL* para sistemas de transci on etiquetados, probando ser igual de
potente que CTL* [28], una logica interpretada sobre estructuras de Kripke.
En su trabajo establecen dos metodos para mapear estructuras de Kripke a
sistemas de transici on etiquetados y viceversa, as como sendas funciones de
transformaci on entre las dos logicas preservando los valores de verdad.
Por tanto, resulta indiferente cual de las dos construcciones escojamos
para la representaci on del conocimiento, puesto que son, de hecho, estruc-
turas equivalentes con el mismo poder expresivo. Siendo ademas ambas ca-
sos especcos de grafos etiquetados, las dos pueden ser representadas sobre
cualquiera de las bases de datos en grafo existentes. Para nuestro proposi-
to tomaremos las estructuras de Kripke como la manera de representar el
conocimiento.
27
6 BASES DE DATOS EN GRAFO.
6. Bases de Datos en Grafo.
Como se nalan Orgun & Ma [64], la potencia de las logicas temporales
ya ha sido satisfactoriamente probada en la resoluci on de problemas como
la especicacion y vericacion de programas [46, 54], el razonamiento tem-
poral [18, 73], la inteligencia articial [76, 6] o las bases de datos tempo-
rales [22, 82, 33]. Sin embargo, aunque en este ultimo campo se han hecho
grandes avances, la mayora de las aproximaciones a sistemas de consulta han
seguido las directrices del algebra relacional, el lenguaje SQL, la ling ustica
computacional o incluso el c alculo de dominios por ejemplos [65]. Es decir,
ninguna de las propuestas ha abandonado el paradigma de las habituales
bases de datos relacionales, transacionales o no. Ocasion de mas para pre-
guntarse que pueden ofrecernos a este respecto las nuevas bases de datos no
relacionales [79] y, en concreto, las bases de datos basadas en grafo, cuyos
lenguajes de consulta est an fuertemente inspirados en repositorios de datos
libres de esquema y algoritmos sobre grafos.
Dentro del grupo de las recien nombradas bases de datos NoSQL [80]
(acr onimo 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 de
motores de bases de datos dise nados y construidos con herramientas actuales
y manteniendo en mente desde un principio la escalabilidad, la latencia de
respuesta, la abilidad y la replicaci on como los puntos centrales. En este
sentido va la queja de Michaek Stonebraker et al. cuando concluye que ((las
lneas de codigo de los actuales sistemas gestores de bases de datos, mientras
intentan ser una soluci on ((que se ajuste a todo)), de hecho, no se ajustan a
nada)), en el sentido de que no pueden competir con las soluciones especcas
que 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 inexi on en el actual panorama de las bases de datos,
produciendose el salto denitivo hacia la nueva generaci on.
Es en este nuevo paradigma en el que se sit uan las bases de datos que basan
su estructura y funcionamiento en la teora 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 actuales
se suelen demandar otro tipo de caractersticas, como las almacenes o caches
clave-valor, los servidores de estructuras, las bases de datos documentales
u orientadas a objetos, y los almacenes de tuplas y por columnas [80]. No
obstante, el desarrollo te orico de los modelos para bases de datos basadas
en grafo es muy anterior. Podemos decir que un modelo de base de datos en
grafo es aquel en el que o bien las estructuras de datos, o bien los propios
datos en s (instancias de la base de datos), o ambos, son modelados como
grafos (dirigidos y/o etiquetados) o como estructuras de datos con la nocion
de grafo (hipergrafos o hipernodos) [3]. Ademas los datos se manipulan a
traves de una serie de primitivas de transformaci on sobre el grafo.
El tercer punto clave en los modelos de bases de datos en grafo es la inte-
gridad de la informaci on, ya que suelen existir mecanismos que garanticen de
alguna manera la consistencia de los datos respecto del esquema, mantengan
la integridad referencial y de los identicadores, y satisfagan las dependencias
funcionales y de inclusi on [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 a
la hora de introducir los datos y las relaciones entre ellos debera colocarse
en una capa superior a la de la persistencia, ya que no implementan (o no
suelen implementar) tales restricciones.
En estos entornos, reejar cualquiera de las estructuras denidas en las
secciones 5.1 y 5.2 resulta trivial, puesto que como se nalamos anteriormente
ambas 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 demostrado
ser satisfactorias desde el punto de vista de las necesidades del mercado. A
continuacion describimos algunas de las mas populares.
29
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
6.1.1. DEX.
DEX
3
[55] es, seg un sus creadores, una ((biblioteca de alto rendimeinto
para gestionar grandes grafos o redes)), en concreto, soporta multigrafos diri-
gidos y etiquetados con atributos. De origen academico, desde marzo de 2010
DEX es mantenida y comercializada por la compa na Sparsity-Technologies
4
,
una entidad saliente de la Universidad Politecnica de Catalu na.
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 investigaci on y evaluaci on s esta permitida. Completamente libre
de esquema, permite la ejecuci on de traversals como metodo de consulta,
aunque no proporciona un lenguaje especco para ello.
6.1.2. FlockDB.
Inicialmente desarrollada para la red social twitter
5
[67], FlockDB
6
es
una base de datos en grafo para la gesti on de datos a escala Web. El sistema
est a construido para ser totalmente distribuido, tolerante a fallos y bajo la
propuesta teorica MapReduce [24].
Liberada como sofware libre bajo una licencia de tipo Apache
7
, los desa-
rrolladores del proyecto deenden que es mucho m as simple que el resto de
bases de datos en grafo existentes, tanto es as que hasta mediados de 2011
no contaba aun con un lenguaje de consulta para grafos.
6.1.3. HyperGraphDB.
HyperGraphDB
8
es un framework de almacenamiento basado en hiper-
grafos generalizados como modelo de datos subyacente. Se podra pensar en
su 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
3
DEX: http://sparsity-technologies.com/dex
4
Sparsity-Technologies: http://www.sparsity-technologies.com
5
Twitter: http://twitter.com
6
FlockDB: https://github.com/twitter/flockdb
7
Apache Licenses: http://www.apache.org/licenses/
8
HyperGraphDB: 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 de
otras aristas. La unidad de almacenamiento es una tupla compuesta de 0 o
m as tuplas donde cada una es llamada un atomo. Cada atomo tiene un va-
lor arbitrario y fuertemente tipado asociado. El sistema de gesti on de tipos
de esos valores est a embebido como un hipergrafo y se puede modicar en
cualquier momento.
HyperGraphDB es en s misma una base de datos embebida con un fra-
mework de distribucion basado en el protoclo XMPP
9
, que ademas funciona
internamente con un almacen clave-valor: una base de datos BerkeleyDB [61].
En su forma actual esta concebida como base de datos orientada a objetos
para Java. El almacenamiento, el indexado y el cacheo han sido dise nados
para permitir consultas sobre el grafo bien por recorridos (traversals) o por
coincidencia de patrones (pattern matching).
Disponible para las plataformas Windows, MacOS y Linux, est a licenciado
bajo los terminos de la Lesser GPL
10
.
6.1.4. InfoGrid.
Pensada para la Web, InfoGrid
11
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 n ucleo de InfoGrid. Puede usarse
de manera autonoma como base de datos en grafo o en conjunci on con
otros proyectos.
Grid Project. Aumenta la capacidad de la base de datos en grafo con
un protocolo para replicacion, de manera que diferentes bases de datos
puedan colaborar gestionando grafos realmente grandes.
Stores Project. Proporciona una interfaz com un para distintas tecno-
logas de almacenamiento tales como bases de datos SQL y tablas hash
9
XMPP Standars Foundation: http://xmpp.org/
10
GNU Lesser General Public License: http://www.opensource.org/licenses/
lgpl-3.0.html
11
InfoGrid: 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. Dene una biblioteca de modelos de objetos
reusable que pueden ser utilizados como esquemas en las aplicaciones.
Con una licencia Aero GPL
12
, InfoGrid ofrece opciones de soporte comer-
cial a traves de la compa na NetMesh
13
.
6.1.5. InniteGraph.
InniteGraph
14
es una base de datos en grafo distribuida dise nada para
soportar aplicaciones que generan modelos de datos en grafo, complejos y
con un gran volumen. Proporciona la capacidad de reducir la escala de los
modelos de datos y grafos en m ultiples bases de datos y m ultiples grafos.
Soporta una variedad de implementaciones de sistema y despliegues, co-
mo pueden ser sistemas basados en servidores, plataformas en la nube o
aplicaciones embebidas. Ofrece una API dedicada para uso directo con el
modelo de datos en grafo junto con una capa de persistencia distribuida y
altamente escalable. Mientras que su arquitectura est a dise nada para sopor-
tar requisitos de alto rendimiento y escalabilidad, la API es muy simple y
en principio solo requiere de un mnimo esfuerzo de desarrollo y dise no para
que los programadores puedan construir r apidamente los sistemas seg un sus
necesidades.
La compa na que se encarga de la licencia de la base de datos es Objectivity,
Inc.
15
, de la que forma parte InniteGraph desde el a no 2010.
12
GNU Aero General Public License: http://www.gnu.org/licenses/agpl-3.0.
html
13
NetMesh: http://netmesh.us/
14
InniteGraph: http://www.infinitegraph.com/
15
Objectivity, 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 Neo4j
16
es quiz as una de las m as conocidas y activamente
desarrolladas, en la que la fuerte implicaci on de la comunidad proporciona el
empuje necesario para que avance en las direcciones que los desarrolladores
demandan.
Neo4j es una base de datos en grafo NoSQL de alto rendimiento, con to-
das las caractersticas de una base de datos robusta y madura. De cara al
programador, ofrece una buena orientaci on a objetos y una estructura de red
exbile, en lugar de estrictas tablas estaticas. Sin embargo, sigue proporcio-
nando todos los benecios de las bases de datos empresariales y completa-
mente transacionales. Se nalan en su web que incluso hay estimaciones sobre
otras 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 para
su edici on Community, y con ediciones Advance y Enterprise disponibles
como Aero GPL y con soporte por la compa na Neo Technology
17
bajo una
licencia comercial.
6.1.7. OrientDB.
OrientDB
18
es un sistema gestor de bases de datos documentales y en
grafo escalable y que presume de ser tan exible como las bases de datos
documentales y tan poderosa para gestionar enlaces como las bases de datos
en grafo. Puede trabajar en modo libre de esquema, con soporte completo
de esquema o en un modo mixto. Soporta caractersticas como transacciones
ACID [38], ndices r apidos, y consultas nativas y SQL. Importa y exporta
documentos en formato JSON
19
.
El algoritmo de indexado es de invenvion propia. Recibe el nombre de
MVRB-Tree y es una derivaci on del Red-Black Tree [75] y los B+Tree [9] pero
con las ventajas de ambos: insercion rapida y b usquedas aun mas r apidas.
16
Neo4j: http://neo4j.org/
17
Neo Technology: http://neotechnology.com/
18
OrientDB: http://www.orientechnologies.com/
19
JSON, 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 soporta
varios billones de registros con una capacidad m axima de billones de terabytes
de datos distribuidos en m ultiples discos en m ultiples nodos.
OrientDB es de libre uso y est a distribuida bajo los terminos de una licencia
Apache 2.0
20
.
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 com un estandarizado
y 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 especcos a una tecnologa o disposicion de los
datos concretos. Es por ello que no podemos s olo describir uno solo sino va-
rios de los lenguajes de consulta desarrollados para atacar bases de datos e
informaci on dispuesta a modo de grafo.
6.2.1. GQL.
GQL [66] es un lenguaje de consultas gr aco basado en el modelo de datos
funcional y que puede expresar todas las consultas del algebra relacional.
6.2.2. GraphLog.
Bas andose en la representacion en grafo tanto de datos y como de consul-
tas, Consens y Mendelzon denieron el lenguaje de consultas llamado Graph-
Log [23]. En GraphLog, las consultas son patrones de grafos y las aristas en
las consultas representan caminos en la base de datos.
A da de hoy no parece existir una implementaci on de referencia funcio-
nal y correcta. El sistema gestor de bases de datos Oracle a nadio soporte
para GraphLog [49], pero se desonoce si los fundamentos que usaron son los
mismos que los expuestos a nivel te orico.
20
Apache 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 denida en [70], Gremlin es un lenguaje
para atravesar grafos (traversal ). Permite consultar un grafo y puede ex-
presar traversals complejos con poco esfuerzo, por lo que resulta util para
explorar y aprender sobre grafos. Mas extensivamente, la idea de aplicar el
algebra de caminos a las redes multi-relacionales ya ha sido explorada con
exito en [15, 53].
Desde el punto de vista tecnico existen varias implementaciones, aunque
se trata de un lenguaje que puede ser usado sobre distinas bases de datos.
Lo que permite independizar las consultas del backend de datos especco.
Por otra parte Gremlin es Turing-completo y proporciona numerosas cons-
trucciones en memoria y computadas para soportar reconimiento de patrones
arbitraros.
6.2.4. PQL.
Como se describe en [23, 57], el origen de PQL est a en el proyecto de
integraci on de datos geneticos GeneSeek. PQL incorpora muchas de las ca-
racterstica de los lenguajes de consultas para datos semi-estructurados y
generaliza el lenguaje StruQL, un lenguaje de consulta tambien para datos
semi-estructurados como el XML que permite construir caminos arbitrarios
sobre las relaciones en un documento sencillo.
A esto se le a nade la habilidad de expresar restricciones sobre los metadatos
como una mejora sobre la curacion de base de datos. Estas restricciones guan
la generacion dinamica de planes de consulta potenciales, lo que permite que
una consulta simple permanezca siendo practicamente la misma incluso en
presencia de esquemas que est an continuamente evolucionando, como es a
menudo el caso de la integraci on de datos.
6.2.5. SPARQL.
El World Wide Web Consortium (W3C) cre o en 2004 el protocolo SPARQL
y el lenguaje de consultas RDF [68]. RDF es un formato de datos en grafo
etiquetado 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, redes
sociales, metadatos sobre artefactos digitales, as como para proporcionar un
medio de integracion sobre orgenes dispares de informaci on. SPARQL, es el
lenguaje de consulta para RDF, est a dise nado para reunir los casos de uso
y requisitos identicados por el grupo de trabajo de RDF Data Access. El
lenguaje est a relacionado ntimamente a las siguientes especicaciones:
La especicaci on del Protocolo SPARQL para RDF (SPORT) que de-
ne el protocolo remoto para efectuar consultas SPARQL y recibir los
resultados.
La especicacion SPARQL Query Results XML Format (RESULTS)
que dene 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-estructurados
y XML [13] con una sintaxis similar a SQL. Funciona sobre las bases de la
recursi on estructural y el pattern matching de forma muy parecida a como
lo hace XLS sobre cheros XML pero deniniendo mecanismos para evitar
entrar en bucles innitos durante la evaluaci on. El algebra interna de UnQL
se denomina UnCAL y dene el concepto de recursion estructural sobre gra-
fos para, posteriormente, poder efectuar consultas sobre el conjunto de datos
aplicando la noci on de que una consulta UnCAL es en realidad una bisimu-
laci on generica.
Las consultas UnCAL son computables en NLOGSPACE, esto es, PTIME,
pero lamentablemente la unica implementaci on real de UnQL, pese a las
indicaciones 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 que
conviene no confundirlo con el sistema de identico nombre
21
desarrollado por
la compa na de reciente aparci on Couchbase
22
para consultar bases de datos
semi-estructuradas, cheros en formato JSON y bases de datos documentales.
Nada, por el momento, para bases de datos en grafo.
21
UnQL: http://www.unqlspec.org/display/UnQL/Home
22
Couchbase Server 2.0: http://www.couchbase.org/get/couchbase/2.0.0
36
7 L

OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE


GRAFOS.
7. Logica temporal de intervalos y consulta
de grafos.
Una vez denidos todos los conceptos necesarios, pasaremos a mostrar
c omo a partir de estos es posible traducir autom aticamente desde una pro-
posicion expresada en un lenguaje temporal a la correspondiente expresi on
en lenguaje de consulta de grafos. A modo de aproximaci on se usaran para
nuestros prop ositos la L ogica Temporal de Intervalos en la que se basa el len-
guaje Tempura, y el lenguaje de consultas Gremlin, de manera que nuestra
estructura de Kripke pueda estar alojada en cualquiera de las bases de datos
soportadas por Rexster
23
.
Usaremos adem as como backend de persistencia la base de datos Neo4j
(secci on 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 de
esta base de datos en grafo. Los estados nales no estaran marcados de ma-
nera alguna debido a que la longitud de cada camino a vericar depender a de
la 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 y
versatilidad de los sistemas de bases de datos basados en grafo, no resulta
muy complicado reejar las primeras en los segundos. De esta manera, si
volvemos a la denicion de la seccion 5.2, podemos decir que una estructura
de 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 la
etiqueta initial.
23
Rexster [70] es un servicio que proporciona una interfaz REST [30] uniforme para
implementaciones de bases de datos en grafo. Ofrece la posiblidad de utilizar el lenguaje
de consultas Gremlin en todas ellas.
37
7.2 Logica temporal sobre lenguaje de consultas para grafos.
7 L

OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE


GRAFOS.
T es una relaci on entre dos nodos etiquetada siempre con next.
l ser a el diccionario que mantiene que propiedades est an en cada no-
do, es decir, mantiene los valores de los atomos en cada estado. En
la practica esta funci on es innecesaria ya que los nodos mantienen la
informaci on sobre sus atributos de manera interna.
7.2. Logica temporal sobre lenguaje de consultas para
grafos.
Como segundo paso antes de construir un algoritmo para conversi on,
necesitamos establecer las equivalencias entre la sintaxis, los modelos, las
interpretaciones y la satisfactibilidad de la l ogica temporal de intervalos y
en lenguaje de consultas escogido. Sea entonces v el nodo de referencia de la
base de datos, que sera expresado como v = g.v(0) en Gremlin.
Denimos ademas un dominio T en el que sea posible operar no s olo con los
valores de verdad true (verdadero) y false (falso), sino con todo el abanico de
operaciones aritmeticas. De esta manera, no basta con establecer un funci on
simple esperando a que esta se eval ue en 0, 1, cada funci on, para que sea
correcta en nuestra propuesta, debe constar al menos de un operador l ogico
comparador, entendiense como tales la igualdad, la desigualdad, mayor que,
menor que, mayor o igual que y menor o igual que. La negaci on, como veremos
m as adelante, no ser a tenida en cuenta y sera tarea del lector efectuar los
cambios necesarios para que su proposicion siga siendo correcta.
7.2.1. Sintaxis.
Las expresiones se construir an de la siguiente manera:
Las variables individuales pasan a ser propiedades de los nodos. No
existen propiedades con valores nulos, es decir, toda propiedad sera un
valor numerico, un valor logico o, en su defecto, una cadena de carac-
teres.
Las funciones que implican variables se eval uan usando la aritmetica
nativa de los lenguajes.
38
7.2 Logica temporal sobre lenguaje de consultas para grafos.
7 L

OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE


GRAFOS.
Operador ((siguiente)) (next): ahora toma el signicado de, a partir de
un nodo, se alcanza el siguiente si desde el primero sale una relaci on
dirigida hacia el segundo etiquetada con next y en el se cumple cier-
ta f ormula. En principio no es estrictamente necesario que la relaci on
este etiquetada, para as dejar la puerta abierta a futuras relaciones
como previous, que podran a nadir una sem antica mucho m as rica.
Los predicados pasan a ser comprobaciones sobre propiedades y fun-
ciones construidas sobre estas, de manera que suponemos denidas re-
laciones como en el lenguaje de consultas.
La igualdad se har a conforme a los operadores l ogicos denidos en el
lenguaje de consulta.
Conectivas l ogicas: w y w
i
w
j
. Si bien, la unica primitiva real que
admitiremos ser a la conjuncion, ya que la negaci on puede obtenerse
modicando las f ormulas y proposiciones para producir el resultado
opuesto, esto es, cambiar = por =, < por , y > por .
Operador ((siempre)) (always): se interpretar a como formulas que se
deben vericar en todos los nodos a partir de aquel en el que sea es-
tablecido el operador. Independientemente del resto de proposiciones
asociadas al nodo, la condicion que acompa na a always siempre debe
ser cierta.
7.2.2. Satisfactibilidad.
Ahora, decimos que una f ormula w es satisfecha en un grafo , o que
el grafo satisface la f ormula w si y s olo si existe al menos una consulta
del grafo que sea posible efectuar, esto es, produzca al menos un camino
de longitud distinta de cero. Buena parte de los lenguajes de consulta sobre
grafos estan basados en pattern matching, por lo que la denici on de consulta
consiste en enumerar una serie de patrones sobre los nodos y sus relaciones
y buscar coincidencias en el grafo. Cada vez que se encuentra un camino
que coincida con el patron denido se devuelve y se sigue inspeccionando el
grafo. Por tanto, la tarea de conversi on consiste en realidad en transformar la
proposici on logica en un patr on que pueda ser buscado en el grafo, de ah que
denamos la sintaxis anterior y podamos incluso extender nuevos operadores
como veremos en la secci on 7.2.3.
39
7.2 Logica temporal sobre lenguaje de consultas para grafos.
7 L

OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE


GRAFOS.
I=1
J=2
I=3
J=1
I=3
J=1
I=3
J=4
I=3
J=4
reference
node
next next
next initial
I=3
J=4
I=3
J=1
I=3
J=1
next
next
next next
Figura 1: Grafo de estados con varios caminos posibles.
A modo de ejemplo supongamos la proposici on temporal expresada en 16
y tomada de [60].
((I = 3) (J = 4)) (16)
Que sera v alida en el grafo de la gura 1, pero no lo sera en el de la gura
2, ambos inspirados tambien en la denici on de estados de intervalo en los
ejemplos de [60].
I=1
J=2
I=3
J=1
I=3
J=1
I=3
J=4
I=3
J=4
reference
node
next next
next initial
next
Figura 2: Grafo de estados simple.
40
7.2 Logica temporal sobre lenguaje de consultas para grafos.
7 L

OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE


GRAFOS.
7.2.3. Interpretaci on.
Las extensiones propias de la l ogica temporal de intervalos tambien ser an
tenidas en cuenta en nuestra analoga te orica, pero con ciertos matices.

V =
0
V , donde V es una propiedad. Es decir, el valor de una
propiedad en un grafo es igual a su valor en el nodo marcado como
inicial, siempre que no este contenida en una proposici on o formula que
implique operadores temporales.

w = true ser a cierto si la f ormula no se cumple en el grafo.


Como mencionamos en la seccion 7.2.1, en principio no soportaremos la
negaci on como operador, por lo que este tipo de proposiciones deber an
ser traducidas a su equivalente

w = false.

e =

1
,...,
||

e, si se tiene que [[ 1. De nuevo el valor


de e se deja sin especicar, esta vez, sobre grafos con un s olo nodo.
En la practica, no contemplar el nodo inicial no tendra ning un efecto,
puesto que de existir s olo un nodo la consulta resultante nunca produ-
cir a resultados.
Y algunos de los operadores secundarios tambien pueden ser denidos sin
problema, aunque no todos. Conviene aclarar que, dado que no se conoce de
antemano la longitud de los caminos que satisfacen una cierta proposici on,
aquellos operadores que deban ser aplicados sobre estados nales lo ser an so-
bre el ultimo nodo del posible camino, identicado tras contabilizar el n umero
m aximo de operadores next anidados que se tenga en la proposici on.

w = true. Para denir el operador ((a veces)) comprobamos la


f ormula w en todos los nodos devueltos por la consulta, siendo obliga-
torio que al menos se cumpla en uno.

len(e) = true

e = [[. El operador longitud tambien se


evaluara a posteriori, comprobando el n umero de nodos en los caminos
devueltos por la consulta.
w
i
w
j
y w
i
w
j
usar an las propias conectivas logicas del lenguaje.
Para la implicaci on habr a que hacer uso de su denici on en base a la
negaci on y la conjunci on y, a su vez, usar la negaci on como el ope-
rador logico comparativo opuesto. Por simplicidad, el operador s olo
podra ser usado dentro de f ormulas y no para componer proposiciones
41
7.2 Logica temporal sobre lenguaje de consultas para grafos.
7 L

OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE


GRAFOS.
que impliquen operadores temporales, ya que esto implicara produ-
cir un arbol de consultas por cada ocurrencia de la disyunci on. Nos
centraremos en casos m as sencillos.
if b thenw
i
else w
j
usar a el operador ternario condicional del lenguaje
si este lo implementa. En caso contrario se construira con la ((negaci on))
y la disyunci on y s olo para expresiones.
w
i
w
j
no tendr a operador equivalente, pero podr a obtenerse a partir
de (w
i
w
j
) (w
j
w
i
).
empty ser a considerado cierto para el (sub)grafo sin nodos o con uni-
camente el nodo de referencia.
more, al tratarse del opuesto a empty, ser a cierto en (sub)grafos con
al menos un nodo distinto al de referencia.
e
i
gets e
j
(more [(e
i
) = e
j
]), recordemos la interpretacion infor-
mal de gets como ((llega a ser)), o ((se convierte en)). Por tanto, habr a que
evaluar si en cada nodo siguiente a aquel en que se tenga e
i
, se tiene
adem as e
j
.
stable e evaluara si la expresi on e se tiene en cada nodo del grafo.
halt w comprueba si w se eval ua a false en todos los nodos salvo el
ultimo, siempre sobre los nodos devueltos por la consulta.
e
i
e
j
, se eval ua en cada nodo que (e
i
= e
j
). Notese la diferencia
fundamental con gets en que s olo eval ua en cada nodo los valores de
las expresiones que se tengan en ese estado.
finw, establecer condiciones a satisfacer en el ultimo nodo de los ca-
minos devueltos.
e
i
e
j
, para la asignaci on temporal bastar a con comprobar las propie-
dades correspondientes en los nodos inicial y nal, teniendo en cuenta
la consideracion inicial sobre los nodos nales.
skip w toma valor true en grafos que tienen un unico nodo sin contar
al de referencia.
42
8 LENGUAJE PYTICLI.
8. Lenguaje Pyticli.
Aunque los lenguajes de consultas sobre grafos son bastante potentes,
necesitamos una capa intermedia de programaci on que admita la sintaxis de
la logica temporal de intervalos y la traduzca a una consulta para grafos
independientemente del lenguaje que implemente cada base de datos. A este
sublenguaje que establece una interfaz com un para intervalos temporales en
Python 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 a
principio de los a nos 90, es un lenguaje intepretado que cuenta con un n ucleo
muy reducido pero facilmente ampliable con modulos externos denominados
paquetes. Algunos de ellos se incluyen en la distribucion est andar de Python
de los distintos sistemas operativos. Uno de estos paquetes habituales es
ast
25
, acr onimo ingles para arboles de sintaxis abstracta, y que permite
que los programas sean capaces de procesar la gram atica de otros programas
escritos en Python proporcionando un conjunto de metodos para parsear,
compilar y ejecutar codigo.

Esta es la pieza angular de Pyticli. Tomando una
expresi on sint acticamente correcta en Python que represente una proposici on
temporal, la obtencion del arbol asociado es directa mediante el metodo
ast.parse, por lo que la construccion de la consulta sobre grafos debe ser el
resultado de recorrer el arbol convenientemente y establecer las condiciones
a cumplir en cada nodo, esto es, el patr on equivalente.
8.1. Sintaxis.
Con la idea de simplicar el algoritmo encargado de procesar el arbol de
sintaxis, el conjunto de operadores y expresiones v alido es el mas limitado
posible.
Constantes. Necesarias para disponer que una proposicion sea cierta o
falsa, nuestro lenguaje cuenta con las constantes logicas true y false,
adem as de cualquier construcci on numerica valida y cadenas de carac-
teres, aunque estas ultimas no ser an utilizadas de momento. Ser an por
tanto constantes validas true, 7, " cadena " y 1.2e-3.
24
Python Programming Language: http://www.python.org/
25
Abstract Syntax Trees: http://docs.python.org/library/ast.html
43
8.1 Sintaxis. 8 LENGUAJE PYTICLI.

Atomos. Los atomos de nuestras proposiciones, que posteriormente


ser an traducidos a propiedades de los nodos, vendr an dados por las
mismas reglas que denen varibles en Python. Son atomos validos J,
mi variable, propiedadCamelCase y propiedadCon1y2numeros; e
inv alidos 1variable y ~ nCaracterNoValido.
Operadores aritmeticos. Los operadores denidos hasta el momento
son, + (suma), - (resta), * (multiplicaci on) y / (divisi on). A los que
se incluyen los operadores necesarios para realizar comparaciones, ==
(igualdad), != (desigualdad), < (menor que), > (mayor que), <= (menor
o igual que) y >= (mayor o igual que).
Operadores logicos. El unico operador logico permitido es la disyuncion,
and.
Operadores temporales. Solo dos operadores temporales b asicos est an
denidos, next y always, con la correspondiente semantica ya discutida
en secciones anteriores.
Expresiones. Entenderemos como expresiones cualquier operaci on aritmeti-
ca sobre atomos y constantes que no implique operadores temporales.
Proposiciones. Una proposici on sera una composici on de operadores
l ogicos, expresiones y operadores temporales. De esta manera next(J==1
and always(I<=2)) ser a una expresion no v alida que tendra que ser
expresada como next(J==1) and next(always(I<=2)).
Tambien estar a permitido modicar la precendecia asociada a los operadores
utilizando para ello los smbolos de parentesis ( y ).
Una gramatica aproximada podra ser la denida a continuaci on:
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 proposici on, si bien puede ser correcta desde el punto
de vista del parser del lenguaje Python, no ser a procesada correctamente por
nuestro algoritmo y de producir una salida no se garantiza en modo alguno
que esta sea valida.
8.2. Limitaciones.
Existen ciertas limitaciones que han de ser tenidas en cuenta. La m as
importante es que la nalidad de esta conversi on no es generar un grafo que
verique la proposici on, sino, dada una proposici on y un grafo, comprobar si
se verica la proposicion sobre el grafo. De ah la conversi on de proposici on
a consulta sobre el grafo.
Por motivos de simplicidad hemos reducido los operadores y smbolos al
conjunto mas basico posible, en resumen, a los operadores , =, next y
always. Mencion especial require la ausencia del operador (negaci on), que
podra resultar indispensable para construir ciertas proposiciones. Sin embar-
go, esta carencia puede ser suplida con el uso de las constantes true y false y
de los operadores de igualdad y desigualdad. Actualmente queda como tarea
del usuario de Pyticli hacer la correspondiente transformaci on de la consulta,
este y otros operadores pueden ser f acilmente preprocesados autom aticamen-
te antes de ser evaluados por Pyticli. Sin embargo, este preprocesado queda
fuera del alcance de este documento, aunque en la seccion 8.5 se indicar an
algunas pautas utiles a seguir en pos de una posible implementaci on.
45
8.3 Algoritmo de conversion. 8 LENGUAJE PYTICLI.
8.3. Algoritmo de conversi on.
El proceso mediante el cual a partir de una proposicion se devuelve una
consulta sobre grafos consta de varias partes. A grandes rasgos vendra descri-
to por el algortimo 1. Dado que la funcion AbstractSyntaxTree es invocada
directamente a traves del metodo parse del paquete de Python ast que pro-
duce el arbol de sintaxis correspondiente, el peso de la conversion recae sobre
las funciones ProcessTree y GenerateQuery. Conviene resaltar la importan-
cia de las estrucuras auxiliares a y n, ambas diccionarios, que almacenar an la
informaci on siguiente una vez que ProcessTree haya terminado su ejecuci on:
El diccionario a tendr a por claves el n umero del nodo (estado) a partir
del cual deben cumplirse las expresiones que tenga denidas en su valor
asociado. Esta claves obedecen al orden en el cu al ha de construirse el
patr on equivalente a la proposici on temporal que se busca traducir.
El diccionario n tambien tendr a como claves el n umero que designa el
nodo en la consulta sobre el grafo, y sus valores ser an las expresiones
que se han de vericar en cada uno de ellos.
Ambas estructuras usan una representacion abstracta para los atomos y las
constantes: los n umeros son encerrados entre los smbolos # y #, las cadenas
de caracteres entre $ y $, los valores de verdad entre < y >, los atomos
que hagan referencia a propiedades del nodo actual entre y , los que
hagan referencia al nodo anterior entre % y %, y los que que se reeren al
nodo inicial entre @ y @ (los dos ultimos casos ser an especialmente utiles
cuando se extienda el lenguaje con funciones como gets o halt). Algunos
ejemplos son:
N umeros: #13#, #1.4#, #-2.4e+10#.
Cadenas: $cadena de caracteres$, $Car acteres extra~ nos$.
Valores l ogicos: <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 representacion
por convenio, esto es, & para el operador disyuncion, == para la igualdad, !=
desigualdad, < menor, > mayor, <= menor o igual que, >= mayor o igual que,
+ suma, - resta, * multiplicaci on y / divisi on.
Algorithm 1 Algoritmo general de conversion: Pyticli
Require: p Temporal Logic Proposition
Ensure: q GraphDatabase Query
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 manipular a los smbolos si-
guiendo este convenio y ser a capaz de producir distintas salidas para distintos
lenguajes de consulta procesando la proposici on inicial una unica vez. El mo-
tivo de esta representaci on abstracta intermedia es independizar la generacion
de la consulta del parseo del arbol sint actico.
Como se aprecia, el n ucleo de funcionamiento de Pyticli es la funcion
ProcessTree que, a su vez, se apoya en otras tantas auxiliares como indica el
algoritmo 2. Su funcionamiento es relativamente sencillo. Cuando el m odulo
ast de Python produce el arbol sint actico, cada expresi on debe ser evaluada
independientemente, puesto que tienen atributos y metodos distintos. As,
el parseo de una proposici on puede ser primero dividido en una funci on de
disyunci on u operaci on 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 (clase
ast.BoolOp), que tienen parte izquierda, y una lista con los comparadores y
los 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 la
que 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 then
2: s
Push
getOperator(t)
3: for value in V alues(t) do
4: ProcessTree(value, a, n)
5: end for
6: if s then
7: s
Pop
8: end if
9: else if t is a ComparationOperation then
10: for i, comparator in getComparators(t) do
11: s
Push
getOperator
i
(t)
12: ProcessTree(getLeftTree(e), a, n)
13: ProcessTree(getRightTree(e), a, n)
14: s StackReduce(s, a, n)
15: end for
16: else if t is a BinaryOperation then
17: s
Push
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 then
22: s
Push
getCallerFunction(t)
23: for argument in getArguments(t) do
24: ProcessTree(argument, a, n)
25: s StackReduce(s, a, n)
26: end for
27: else if t is an Atom then
28: s
Push
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 deber a inspeccionar el
contenido de la misma y operar en consecuencia. Este procedimiento, ilustra-
do en 3, es el encargado de generar las estructuras abstractas que almacenan
la informaci on correspondiente a las condiciones a vericar en los estados,
tanto para el operador next como always. En cada llamada exitosa a Stac-
kReduce, el tama no de la pila disminuye, pasando los elementos eliminados
a formar parte de las estructuras antes mencionadas. El funcionamiento del
algoritmo es sencillo: va extrayendo los elementos de la pila y comprobando
que cada tripleta extrada se corresponde con una expresi on v alida, en cuyo
caso puede tomar dos decisiones:
La expresi on es una operaci on aritmetica, en cuyo caso simplemente se
a nade como un elemento atomico en la pila.
La expresi on es una operaci on logica, por lo que debera a nadirse al
diccionario correspondiente, a para operadores always y n para ope-
radores next, junto al operador l ogico que la acompa na si procede. Es
decir, se asume por defecto que las operaciones logicas solo usan el
operador , pero se deja la puerta abierta para soportar la disyuncion.
Si no encuentra una expresi on v alida que formar con los primeros 3 elementos
de la pila, entonces devuelve la pila sin modicar.
El proceso anterior est a tambien apoyado en una batera de funciones
y metodos auxiliares de los que hay que destacar la funcion StackSplit,
encargada de inspeccionar la pila en busca de llamadas anidades de los
operadores always y next, identicando a partir de que estado o exacta-
mente en cu ales deben satisfacerse las expresiones a las que acompa nan.
Por ejemplo, si en un estado concreto de la ejecucion se tiene que la pila
s = 'next, always, next, next, expr`, sera equivalente a tener siempre expr a
partir del estado 3. Sin embargo, aunque esta asuncion puede resultar tri-
vial, no ha sido posible localizar una demostracion valida que la sustente en
la literatura relacionada, salvo, quizas, algunas nociones parecidas aunque in-
completas en [10]. Por tanto, queda su demostracion formal emplazada como
trabajo 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 s
if s
Length
3 then
right r
Pop
left r
Pop
if left and right are V alidComparators then
operator r
Pop
expr 'right, operator, left`
if operator is an ArithmeticOperator then
r
Push
expr
r StackReduce(r, a, n)
else if operator is a LogicOperator then
always, next, logic StackSplit(r)
if always then
a
Add
(next, logic, expr)
else
n
Add
(next, logic, expr)
end if
else
r s
end if
else
r s
end if
end if
return r
50
8.4 Aplicaciones. 8 LENGUAJE PYTICLI.
8.4. Aplicaciones.
Como se comento en la secci on 1, el presente proyecto no pretende ser
una soluci on para vericaci on de modelos sino, m as bien, una herramienta
complementaria que permita, a partir del grafo de las trazas generadas por
un sistema ya en funcionamiento, comprobar si las proposiciones tempora-
les usadas en su concepci on siguen siendo vericadas (satisfactibles). Esto
permitira, por ejemplo, centralizar el repositorio de trazas de un sistema
de sensores y consultar en tiempo real si el funcionamiento es el esperado
simplemente recurriendo al conjunto de proposiciones usado en su dise no.
En este sentido, y tomando como base el amplio catalogo de ejemplos
de [60], se muestran a continuacion algunas de las correspondencias entre
f ormulas expresadas en ITL y sus equivalentes en Pyticli.
8.4.1. Operadores basicos.
Las primeras formulas de ITL sintacticamente correctas en aparecer son
las 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 construcci on de proposiciones basicas en Pyticli a partir de
la original expresada en ITL, ya que la unica consideraci on a tener en cuenta
es la negacion, que s olo puede aplicarse a las comparaciones. Por tanto, la
f ormula (23) no tendra ning un equivalente posible, ya que, como vimos en
la seccion 8.5, implicara la nocion del operador sometimes.
(J = 2) (I = 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, no
presentan mayor problema.
Ejemplo: implicacion. Aplicando las construcciones logicas convencio-
nales para la conjuncion y la implicaci on, 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 f ormula (28) trata de comprobar
que 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 una
serie de decisiones sobre Pyticli que redujeron su versatilidad. Entre estas
decisiones esta la ausencia de soporte para las operaciones de negaci on y
conjunci on en las proposiciones, el reducido juego de operadores temporales
y el soporte para un unico lenguaje de consulta de grafos como salida, esto es,
Gremlin. Sin embargo, gracias a su dise no altamente modular y estructurado
y a la representaci on interna de las proposiciones, existen algunas vas para
solventar 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 usuario
de Pyticli prepare primero su proposicion y expanda las negaciones que en-
cuentre en sus expresiones con los correspondientes operadores negados. De
esta manera, usando el algebra de Boole, habra que obtener las equivalencias
sustituyendo donde proceda == por !=, != por ==, < por >=, y <= por >, > por
<=, y >= por <. Este procedimiento podra automatizarse dentro de la funcion
StackReduce 3, de forma que si el segundo elemento de la pila es el operador
de negaci on, todas las comparaciones del primer elemento de la pila deben
ser sustituidas por su negaci on y, nalmente, apilar la nueva expresi on. Un
mecanismo parecido podra seguirse para el operador conjunci on .
Sin embargo conviene resaltar que con el procedimiento descrito s olo sera
posible utilizar la negaci on y la conjuncion en expresiones que no impli-
quen operadores temporales. Esto es, al encontrar una expresi on del ti-
po not(next(J==2)), nuestra propuesta funcionara correctamente, pero en
cambio no resolvera correctamente expresiones del tipo not(next(J==2)
and always(I==1)), ya que not(always(I==1)), que sera equivalente a
sometimes(I==1), no est a aun contemplado en Pyticli.
8.5.2. Operadores temporales.
Otros operadores temporales como gets, halt o fin s seran facilmente
implementables utilizando las propiedades de los estados inicial, anterior y
actual descritas en la secci on 8.3. Otros operadores, como sometimes o equiv
(w
i
w
j
), que requieren de una comprobaci on a posteriori sobre los estados
de los caminos posibles devueltos por la consulta, no son tan facilmente
implementables.
8.5.3. Lenguajes de salida.
Para enriquecer Pyticli con nuevos lenguajes basta con crear una nueva
clase Python que extienda pyticli.languages.BaseQueryLanguage y que
implemente el metodo generate cuyo unico parametro es el valor logico
verbose. Esta clase proporciona en la variable self.states una lista con
las expresiones a satisfacer en cada estado convenientemente abstradas y
tras 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 valores
de self.states, construir la consulta en Gremlin es realmente sencillo, pues
basta con recorrerlos e ir adaptando las expresiones a la sintaxis del lenguaje
en cuesti on. La funcion flatten es, en este caso, la encargada de traducir las
representaciones abstractas de los atomos a las correspondientes expresiones
nativas en Gremlin.
1 def gener at e ( s e l f , ver bos e=Fal s e ) :
2 i f ver bos e :
3 s e par at or = `n
4 el se :
5 s e par at or =
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 at e s c ount ) :
8 query = % s % s % ( query , s e par at or )
9 i f i in s e l f . s t a t e s :
10 val = 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 de Ef f e c t i n i t=i t . map( ) ; `
13 prev % s=i t . map( ) . outE` next ` `
14 % ( query , val , i )
15 el se :
16 query = % s . inV % s . s i de Ef f e c t `
17 prev % s=i t . map( ) . outE` next ` `
18 % ( query , val , i )
19 el se :
20 i f i == 0:
21 query = % s . inV . s i de Ef f e c t i n i t=i t . map( ) ; `
22 prev % s=i t . map( ) . outE` next ` `
23 % ( query , i )
24 el se :
25 query = % s . inV . s i de Ef f e c t `
26 prev % s=i t . map( ) . outE` next ` `
27 % ( query , i )
28 query = % s % s . paths . uni que ( ) % ( query , s e par at or )
29 return query
Listing 1: Funci on 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 b asica pero
funcional, con la cual se pueden hacer pruebas de conversi on entre propo-
siciones e incluso conectar con una base de datos en grafo real a la que
atacar directamente. El comportamiento por defecto se limita a, dada una
proposici on en Pyticli para ITL, devolver la consulta equivalente en Gremlin.
Soporta, ademas, un reducido conjunto de comandos:
verbose, que puede ir acompa nado de on u off y permite activar
la impresi on de la estructura intermedia utilizada para representar la
proposici on de manera abstracta.
connect, con 2 parametros, el primero especica el tipo de base de
datos a la que se va a conectar, y el segundo la cadena de conexi on.
De momento s olo esta disponible la base de datos Neo4j a traves de
su cliente REST para Python
26
. Una vez que la conexi on es estableci-
da, cada conversi on de proposicion devuelve, adem as, el resultado de
ejecutar la consulta resultante sobre la base de datos en cuesti on.
disconnect, para desconectar de la base de datos si hay alguna cone-
xi on establecida. Solo una conexion puede estar activa, por lo que es
necesario 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 con
alguna.
help, sin parametros imprime la ayuda general de la consola. Acom-
pa nado de otro comando muestra la ayuda especca de este.
exit, para terminar la sesion de la consola.
Una sesi on habitual de la consola puede ser la mostrada en 8.6 (el smbolo
:> simboliza la entrada o prompt de la consola).
$ python shell.py
Pyticli 0.0.3 by Javier de la Rosa.
26
An 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 est a liberado bajo una
licencia libre GNU General Public License
27
y disponible en un repositorio
de c odigo en la plataforma para desarrolladores GitHub
28
. Ademas, se ha
incluido una versi on 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 revisi on de
empaquetado, pues lo deseable sera que una vez instalada se puede utilizar
simplemente escribiendo pyticli en la terminal de comandos del sistema
operativo (de momento s olo probado s olo en sistemas basados en Linux).
27
GNU General Public License: http://www.gnu.org/licenses/gpl.html
28
Python Temporal Intervals Common Language Interface: http://github.com/
versae/pyticli
29
A 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, l ogica temporal de intervalos, que pueden estar sopor-
tados por construcciones denominadas estructuras de Kripke. Hemos visto
que existe una equivalencia a nivel de representacion entre estas estructuras
y los grafos reproducibles en bases de datos en grafo reales. Con la posbili-
dad potencial de almacenar billones de proposiciones formando estructuras
de Kripke masivas, Pyticli ofrece un proxy capaz de convertir proposiciones
de ITL a consultas sobre el grafo, siendo capaz de generar una respuesta
sobre la satisfactibilidad de la proposici on. Lo que cuadra con lo propuesto
en [84, 85].
Queda como trabajo futuro realizar un an alisis m as profundo de las impli-
caciones de la equivalencia entre grafos y estructuras de Kripke, y entre ITL
y Gremlin.
Por otra parte, sera interesante estudiar en profundiad las similitudes
entre el algebra de caminos y las construcciones en logica temporal, as como
los modelos de Herbrand [83] para una posible implementaci on general del
metodo que pueda extenderse a un lenguaje de consultas te orico sobre la
l ogica temporal.
58
REFERENCIAS
10. Bibliografa.
Referencias
[1] M. Abadi & Z. Manna. Temporal logic programming. In Proceedings of the
1987 Symposium on Logic Programming, 416. IEEE Computer Society
Press, 1987.
[2] M. Abadi & Z. Manna. Temporal logic programming. Journal of Symbolic
Computation, 8:277295, 1989.
[3] R. Angles & C. Gutierrez. Survey of Graph Database Models. Technical
Report TR/DCC-2005-10, Computer Science Department, Universidad de
Chile, 2005.
[4] T. Aoyagi, M. Fujita, & T. Moto-oka. Temporal logic programming lan-
guage Tokio. In E. Wada, editor, Logic Programming85, 221:138147.
Springer-Verlag, 1986.
[5] A. W. Appel & D. B. MacQueen. A standard ml compiler. Functional
Programming Languages and Computer Architecture, 1987.
[6] F. Baader. Logic-based knowledge representation. In Articial Intelligen-
ce Today: Recent Trends and Developments, page 13. Springer, 1999.
[7] P. Balbiani, A. Herzig, & M Lima-Marques. TIM: The Toulouse inference
machine for non-classical logic programming. In PDK91: International
Workshop on Processing Declarative Knowledge, volume 567 of LNAI,
pages 365382. Springer-Verlag, 1991.
[8] P. Balbiani, A. Herzig, & M. Lima-Marques. Implementing Prolog ex-
tensions: a parallel inference machine. In Proc. of the 1992 International
Conference on Fifth Generation Computer System, pages 833842. ICOT,
1992.
[9] R. Bayer & E. M. McCreight. Organization and Maintenance of Large
Ordered Indices. In Acta Informatica, 1: 173189. 1972.
[10] P. Blackburn, M. de Rijke & Y. Venema. Modal logic, 53. Cambridge
University 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. Gr umberg. Characterizing nite Krip-
ke structures in propositional temporal logic, In Theoretical Computer
Science, 59(12): 115131, 1988.
[13] P. Buneman, M. Fernandez & D. Suciu. UnQL: a query language and
algebra for semistructured data based on structural recursion. In The
VLDB Journal, 9(1): 76110. Springer, 2000.
[14] J. P. Burgess. Basic tense logic. In D. M. Gabbay and F. Guethner, edi-
tors, Handbook of Philosophical Logic, 2(89): 89134. D. Reidel Publishing
Company, 1984.
[15] B. Carre. Graphs and Networks, Oxford University Press, 1979.
[16] A. Chandra, J. Halpern, A. Meyer & R. Parikh. Equations between
regular terms and an application to process logic. In Proceedings of the
Thirteenth Annual ACM Symposium on Theory of Computing, 384390,
Milwaukee, Wisconsin, 1981.
[17] M. Chein & M. L. Mugnier. Simple Conceptual Graphs, Graph-based
Knowledge Representation, series Advanced Information and Knowledge
Processing, 5981, 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-Standard
Logics for Automated Reasoning, pages 81103. Academic Press, 1988.
[19] E. M. Clarke, D. E. Long & K. L. McMillan. Compositional model chec-
king. In Logic in Computer Science, 1989. LICS89, Proceedings., Fourth
Annual Symposium on, 353362. IEEE, 1989.
[20] E. Clarke. Model checking. In Foundations of software technology and
theoretical computer science, 5456. Springetr, 1997.
[21] G. Cleary & V. N. Kaushik. Updates in a temporal logic programming
language. Technical report, Department of Computer Science, University
of Calgary, Calgary, Alberta, Canada, 1991.
60
REFERENCIAS REFERENCIAS
[22] J. Cliford & D. S. Warren. Formal semantics for time in databases. ACM
Transactions on Database Systems, 8(2):214254, June 1983.
[23] M. P. Consens, A. O. Mendelzon, Graphlog: a visual formalism for real
life recursion. In Proceedings of the Symposium on Principles of Database
Systems, 404416. ACM, New York, NY, 1990.
[24] J. Dean S. Ghemawat. MapReduce: simplied data processing on large
clusters, In Commun. ACM 51(1): 107113, New York, NY, USA, 2008.
[25] R. De Nicola & F. Vaandrager. Action versus state based logics for
transition systems. In Semantics of Systems of Concurrent Processes, 407
410, Springer, 1990.
[26] E. Eifrem. Neo4j The Benets 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: Branching
time strikes back. Science of Computer Programming, 8:275306. 1986.
[29] J. L. Fern andez Vindel, A. Manjarres Riesco & F. J. Dez Vegas. Logica
Computacional. Dpto. Inteligencia Articial, E.T.S.I. Inform atica. UNED,
2007.
[30] R. T. Fielding. Architectural Styles and the Design of Network-based
Software 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, 197237. Academic Press,
1987.
[32] D. M. Gabbay. A temporal logic programming machine [modal and tem-
poral logic programming, Part 2]. Department of Computing, Imperial
College, 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 423430,
Barcelona, Spain, September 1991. Morgan Kaufman, Los Altos, Califor-
nia.
[34] M. Graves, E. R. Bergeman, & C. B. Lawrence. Graph Database Systems
for Genomics. In IEEE Engineering in Medicine and Biology. Special issue
on Managing Data for the Human Genome Project 11, 6, 1995.
[35] R. Hale. Temporal logic programming. In A. Galton, editor, Temporal
Logics and Their Applications, 91119. Academic Press, 1987.
[36] J. Halpern, Z. Manna & B. Moszkowski. A hardware semantics based on
temporal intervals. In Proceedings of the 10-th International Colloquium
on Automata, Languages and Programming, 154: 278291, Lecture Notes
in Computer Science, Springer Verlag, Berlin, 1983.
[37] J. Halpern, Z. Manna & B. Moszkowski. A hardware semantics based on
temporal intervals. In Proceedings of the 10-th International Colloquium
on Automata, Languages and Programming, 154: 278291, in the series
Lecture Notes in Computer Science, Springer Verlag, Berlin, 1983.
[38] T. Harder & A. Reuter. Principles of Transaction-Oriented Database
Recovery. In ACM Computing Surveys 15(4): 287317. 1983.
[39] D. Harel, D. Kozen & R. Parikh. Process logic: Expressiveness, decida-
bility, completeness. In Journal of Computer and System Sciences, 25(2):
144170, 1982.
[40] T. Hrycej. Temporal Prolog. In Proc. of the European Conference on
Articial Intelligence, 296301, Munich, Germany, 1988.
[41] T. Hrycej. A temporal extension of Prolog. Journal of Logic Program-
ming, 15: 113145, 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 Function
Articial Intelligence 2: 227-60, 1971.
62
REFERENCIAS REFERENCIAS
[44] R. A. Kowalski. Predicate logic as programming language. In Proceedings
of IFIP74, 569574, Amsterdam, 1974.
[45] S. Kripke. Semantical considerations on modal logic. In Acta philosop-
hica fennica, 16(1963): 8394. 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): 379413, 1993
[48] N. Leavitt. Will NoSQL databases live up to their promise?. In Compu-
ter, 43(2): 1214. IEEE, 2000.
[49] U. Leser. A query language for biological networks. Bioinformatics 21(2):
3339. 2005.
[50] M. Levene & A. Poulovassilis. An Object-Oriented Data Model Forma-
lised Through Hypergraphs. Data & Knowledge Engineering (DKE) 6(3):
205224, 1991.
[51] S. Litt. NoSQL: The Unix Database (With awk). Linux Productivity
Magazine, 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 nding paths in graphs. In Procee-
dings of the International Conference on Information Technology Interfa-
ces, 1: 657662. 2004.
[54] Z. Manna & A. Pnueli. Verication of concurrent programs: the tem-
poral framework. In Boyer and Moore, editors, Correctness Problem in
Computer Science, pages 215273. Academic Press, 1981.
[55] N. Martnez-Bazan, V. Muntes-Mulero, S. Gomez-Villamor, J. Nin, M.
S anchez-Martnez & J. Larriba-Pey. 2007. Dex: high-performance explo-
ration on large graphs for information retrieval. In Proceedings of the
Sixteenth 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 modal
logic. In Journal of Symbolic Logic, 10:8396, 1945.
[57] P. Mork, R. Shaker, A. Halevy, & P. Tarczy-Hornoch. PQL: a declarative
query language over dynamic biological schemata. In Proceedings of the
AMIA 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 STANCS83970.)
[59] B. Moszkowski. A temporal logic for multilevel reasoning about hard-
ware. Computer 18, 2: 1019, 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 the
FREENIX Track: 1999 USENIX Annual Technical Conference, 183192,
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, 2350. Oxford
University Press, 1992.
[64] M. A. Orgun & W. Ma. An Overview of Temporal and Modal Logic
Programming. In Temporal Logic, pages 445479. Springer, 1994.
[65] G. Ozsoyoglu & R.T. Snodgrass. Temporal and real-time databases: A
survey. In Knowledge and Data Engineering, IEEE Transactions on, 7(4):
513532. 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):
325, 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. Prudhommeaux & A. Seaborne. SPARQL query language for RDF.
Tech. rep., World Wide Web Consortium, 2004. Accessed on July 2011
http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/
[69] L. Richardson & S. Ruby. RESTful Web Services. 2007. OReilly Media,
Inc.
[70] M. A. Rodriguez, J. Shinavier. Exposing Multi-Relational Networks to
Single-Relational Network Analysis Algorithms, Journal of Informetrics,
4(1): 2941. 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 121168. 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. Dobbs Journal, 17(4): 4246. 1992.
[76] P. Smets, A. Mamdani, D. Dubois, & H. Prade, editors. Non-Standard
Logics 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(25): 7593, 1992.
65
REFERENCIAS REFERENCIAS
[79] M. Stonebraker. SQL databases v. NoSQL databases. In Communica-
tions of the ACM, 53(4): 1011. ACM, 2010.
[80] C. Strauch. NoSQL Databases, Selected Topics on Software-Technology
Ultra-Large Scale Sites. Thesis on Computer Science and Media, Stuttgart
Media University, 2011.
[81] J. Tretmans. Model based testing with labelled transition systems. Formal
methods and testing, 138, Springer-Verlag, 2008.
[82] A. Tuzhilin & J. Cliford. A temporal relational algebra as a basis for
temporal relational completeness. In D. McLeod, R. Sacks-Davis, & H.
Schek, editors, Proceedings of the 16th International Conference on Very
Large Data Bases, pages 1323, Brisbane, Australia, August 1316 1990.
Morgan Kaufmann Publishers Inc., Los Altos, California.
[83] M. H. Van Emden & R. A. Kowalski. The semantics of predicate logic
as a programming language. In Journal of the ACM (JACM), 23(4): 733
742, 1976.
[84] M. Vardi & P. Wolper. An automata-theoretic approach to automatic
program verication. In Proceedings of the First Symposium on Logic in
Computer Science, 322331, 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. In
Proceedings of the 1988 International Symposium on Lucid and Intensio-
nal Programming, 2632, Sidney, B.C., Canada, 1988.
66

You might also like