Pyticli: satisfactibilidad de

proposiciones en l´ogica 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 Artificial
Universidad de Sevilla
26 de agosto de 2011
Resumen
El presente documento es el trabajo final del M´aster en L´ogica,
Computabilidad e Inteligencia Artificial impartido por la Universidad
de Sevilla en el curso acad´emico 2010–2011.
Presenta el lenguaje Pyticli, un sub-lenguaje del lenguaje de pro-
gramaci´on Python, construido para traducir proposiciones de l´ogica
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 reducci´on para construir una representaci´on
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 Andr´es Cord´ on Franco, acordon@us.es.
1
((Ay, Piticli, bonico, Piticli, ay, Piticli))
1
.
Agradecimientos.
Este trabajo no ser´ıa posible sin la paciencia y compresi´ on del profesorado
del M´aster en L´ ogica, Computaci´on e Inteligencia Artificial, que han mostra-
do su car´acter m´ as humano permiti´endome 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 Andr´es Cord´ on, director
del trabajo, por todos sus comentarios y correcciones in extremis; a Joaqu´ın
Borrego por implicarse en que este documento sea posible y adem´ as est´e 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
ser´ıan bien distintos.
No quiero tampoco olvidar la labor de Juan Luis Su´arez, profesor de la
University of Western-Ontario, qui´en 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 elaboraci´on de este proyecto.
Por ´ ultimo quisiera dar las gracias a todos los que me han apoyado desde
Espa˜ na, Reino Unido y Canad´a, 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
confianza diarias no podr´ıa haber aguantado hasta el final. 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. Interpretaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Programaci´ on L´ogica. 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 reificada. . . . . . . . . . . . . . . . . 22
4.3.1. Temporal Prolog de Hrycej. . . . . . . . . . . . . . . . 22
4.3.2. Starlog. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Representaci´ on del conocimiento. 24
5.1. Sistemas de transici´on 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. InfiniteGraph. . . . . . . . . . . . . . . . . . . . . . . . 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. Interpretaci´on. . . . . . . . . . . . . . . . . . . . . . . 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.Bibliograf´ıa. 59
4
´
INDICE DE FIGURAS LIST OF ALGORITHMS
´
Indice de figuras
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 analog´ıas entre la l´ ogica modal proposicional
temporal (en adelante l´ ogica temporal) y el dominio de la teor´ıa 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 definir 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
definici´ on de modelos concurrentes. Recientemente, la Association for Com-
puting Machinery (ACM) concedi´o el Premio Turing a los creadores de un
mecanismo autom´ atico de verificaci´ on de estos modelos
2
, t´ecnica 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 finalidad ´ ultima de este trabajo es proporcio-
nar un marco pr´actico sobre el cual poder verificar proposiciones espec´ıficas
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 s´olo un
m´etodo de almacenamiento eficaz, robusto, masivo y colaborativo, sino un
mecanismo para realizar consultas sobre los datos a trav´es 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 t´ecnica 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 definimos el proceso mediante el cual, dado un sistema de estados, es ne-
cesario averiguar si un cierto conjunto de proposiciones se verifica, tendr´ıamos
lo que se conoce como model checking [20]. Esta t´ecnica 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 m´etodo radica en que utiliza una representaci´on simb´oli-
ca del espacio de estados, por lo que no debe enfrentarse a limitaciones de
espacio f´ısico de almacenamiento. A trav´es del µ-C´ alculo y una l´ ogica tem-
poral espec´ıfica (CTL) es capaz de manipular f´ormulas y relaciones y decidir
sobre la satisfactibilidad de f´ ormulas expresdas en l´ ogica temporal lineal, evi-
tando as´ı el problema conocido como explosi´on de estados –se conoce como
explosi´on de estados al incremento exponencial de estados que se da al inten-
tar verificar un sistema concurrente. Este problema releg´ o en un principio la
verificaci´ on autom´atica 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 eficientemente, la cantidad m´axima de estados posibles en
un sistema se incrementa de nuevo, pudiendo ahora esta t´ecnica ser aplicada
en m´aquinas de caracter´ısticas sencillas y asequibles.
A posteriori, el algoritmo de conversi´ on de proposiciones de l´ogica 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 an´ali-
sis y definici´ on de las l´ogicas 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 secci´on hace una breve introducci´on 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 espec´ıficamente en los Sistemas de Tran-
sici´ on Etiquetados, usados en la l´ogica 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 definici´on de las bases de datos basadas en
grafo, que vienen a integrar el grupo de las reci´en nombradas NoSQL (que
conviene no confundir con el gestor de bases de datos de id´entico nombre [51])
tambi´en 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 eficientemente
en disco. Los ´ ultimos apartados se dejan para las conclusiones y el posterior
trabajo futuro.
8
2 L
´
OGICA MODAL.
2. L´ogica Modal.
Las l´ ogicas modales forman parte de las l´ogicas formales y ampl´ıan 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 s´ımbolos 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
definidos cada uno en funci´on del otro como se muestra en (1 , 2).
p = q (1)
p = q (2)
Existe pues una clara analog´ıa con los cuantificadores 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 l´ogica modal es la necesita-
ci´on (5), y junto al modus ponens de la l´ogica proposicional permiten definir
distintos tipos de sistema.
¬ φ
¬ φ
(5)
Cada sistema est´ a basado en unos axiomas y dependiendo de cu´ales y
cu´ antos utilice ser´a posible demostrar un mayor o menor n´ umero de teo-
remas. As´ı, partiendo del axioma m´ as b´asico, 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 interpretaci´on. Los axiomas
de K tambi´en incluyen todas las instancias de las tautolog´ıas de la l´ ogica
proposicional.
(φ →ψ) →(φ →ψ) (6)
φ ↔φ (7)
De manera que las reglas para una K-prueba son:
9
2.1 L´ogica Temporal. 2 L
´
OGICA MODAL.
Modus ponens. Dados φ y φ =⇒ ψ, se tiene ψ.
Sustituci´on (uniforme). Dado φ se tiene θ, donde θ se obtiene a partir
de φ reemplazando uniformemente los ´ atomos de la proposici´on en φ
por f´ ormulas arbitrarias.
Generalizaci´on. Dado φ, se tiene φ.
Si definimos como estructura relacional la tupla 'W, R
1
, . . . , R
k
` tal que W
es un conjunto no vac´ıo y cada R
i
es una relaci´on sobre W, podemos definir
una interpretaci´ on o modelo como la tupla ´= 'F, v`, donde:
T es un marco definido por la tupla 'W, R` y donde:
• W es un conjunto no vac´ıo de elementos que reciben el nombre de
mundos posibles.
• R es una relaci´ on entre los mundos posibles denominada relaci´on
de accesibilidad. La relaci´on de accesibilidad puede ser reflexiva,
transitiva, eucl´ıdea y/o sim´etrica, 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 s´ımbolo proposicional el subconjunto de mundos
donde es verdadera.
2.1. L´ogica Temporal.
La l´ogica temporal [14, 72] puede verse como una instancia de la l´ogica
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).
Tambi´en 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 espec´ıficos seg´ un las
restricciones que se incluyan sobre las relaciones. As´ı, un marco adecuado
para la l´ogica temporal b´ asica podr´ıa incluir dos relaciones binarias [29], R
P
y R
F
, que facilitasen las definiciones de transitividad y reciprocidad (l´ogica
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 f´ormula de McKinsey [56], GFφ → FGφ, algo as´ı como
un reflejo de la noci´on termodin´amica de la distribuci´on de la informaci´ on.
3. L´ogica Temporal de Intervalos.
La L´ogica 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 s´ımbolos 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 tambi´en por v´alidas 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 predefinidas funciones aritm´eticas 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 f´ormulas 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 tambi´en suponemos definidas 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
significado a cada s´ımbolo de predicado y funci´on. 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 s´ımbolo de funci´ on f tiene una interpretaci´on ´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 Σ, definimos I = Σ
+
como el conjunto de todas las secuencias finitas y
no vac´ıas de estados. La longitud de un intervalo σ ∈ I vendr´ a dada por [σ[
y se corresponder´a con el n´ umero de estados en el intervalo menos uno, de
manera que cada intervalo estar´a 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 significado 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 v´alida (13).
[= w (13)
3.4. Interpretaci´ on.
Para dar significado a expresiones y f´ormulas sobre intervalos, definimos
´
σ
e como el valor en T de la expresi´ on e en el intervalo σ. An´alogamente,
´
σ
w ser´ a el resultado l´ ogico (true o false) de la f´ormula w en σ. Puede
a veces encontrarse esta notaci´ on de forma abreviada eliminando la notaci´on
de modelo (14)
´
σ
e ≡ e
σ
(14)
´
σ
w ≡ w
σ
(15)
El listado de definiciones 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 interpretaci´on del s´ımbolo de funci´on 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 definici´ 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 especificar 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 definiciones 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 definido 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
ser´ıa equivalente a (w
i
∧ w
j
)
w
i
⊃ w
j
, la implicaci´ on vendr´ıa dada por w
i
∨ w
j
if b thenw
i
else w
j
. La construcci´on del condicional se hace utilizando
el operador de implicaci´ on, (b ⊃ w
i
) ∧ (b ⊃ w
j
).
w
i
≡ w
j
se obtendr´ıa 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 vendr´ıa 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
. Podr´ıamos hacer una lectura aproximada
interpretando gets como ((llega a ser)), o ((se convierte en)).
stable e ≡ e gets e, para expresiones que no var´ıan con el paso del tiem-
po.
halt w tendr´ıa una definici´on equivalente a (w ≡ empty), es decir,
comprueba si w se eval´ ua a false en todos los estados salvo el ´ ultimo,
donde deber´ıa ser cierta para que halt w = true.
e
i
≈ e
j
, se conoce como igualdad temporal es cierta si y s´olo si (e
i
=
e
j
).
14
3.4 Interpretaci´ on. 3 L
´
OGICA TEMPORAL DE INTERVALOS.
w (w. Es el operador weak next cuya definici´on viene dada por empty ∨
w. Se interpreta como la versi´on d´ebil del operador next en el sen-
tido de que su valor tambi´en es true incluso cuando el intervalo tiene
longitud 0.
finw, definido 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 d´ebil 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,
verificar que el valor de e
j
en el estado final σ
|σ|
es el mismo que el de
e
i
en el estado inicial σ
0
. Podr´ıamos decir que es una forma de post-
condici´ on que busca ser verificada si la relaci´ on entre e
i
y e
j
se mantiene
constante entre los estados inicial y final.
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 definidos 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
definiremos formalmente. El operador chop puede ser usado para la defini-
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
definir 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 s´ımbolo ;, 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 composici´on, 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 l´ogicos 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 l´ogicos deber´ıan
especificar qu´e va a ser computado; no c´omo va a ser computado)). Es decir,
mientras que en la programaci´ on algor´ıtmica, 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 programaci´on declarativa en la que se incluye la programaci´ on
l´ ogica s´ olo se deber´ıan especificar el conocimiento y las asunciones que sobre
un problema espec´ıfico se tiene. Lo que se consigue por medio de las llama-
das cl´ ausulas de Horn (cl´ausulas 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 cl´ausulas se
corresponda con la ejecuci´ on del programa.
Denotamos como cl´ausula 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 s´olo
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 f´ormula cierta,
entonces A tambien lo es.
Las cl´ausulas de Horn se clasifican en dos tipos:
Cl´ausula objetivo u objetivo, aquella que no tiene literales positivos,
B
1
∨ . . . ∨ B
n
, donde cada B
i
es un sub-objetivo.
Cl´ausula 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 cl´ausula unitaria o hecho y se interpreta
que A es una f´ormula cierta para cada asignaci´on de cada variable. Al
conjunto de hechos b´asicos se le suele denominar base de datos.
De esta manera podemos definir 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 m´etodo de resoluci´on lineal selectiva con cl´ ausulas definidas o SLD [43],
un m´etodo adecuado y completo cuando se aplica en sistemas de cl´ausulas
de Horn. B´ asicamente el m´etodo 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 derivaci´on SLD finita de P ∪ G que
tiene la cl´ausula vac´ıa como ´ ultimo objetivo en la derivaci´ on. El m´etodo se
desarrolla por recursi´ on mediante sustituci´ on por unificaci´ on. En realidad se
define impl´ıcitamente un ´ arbol de b´ usqueda de las computaciones alternati-
vas aplicando razonamiento con vuelta atr´as, de forma que la ra´ız 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 vac´ıa. Si la cl´ ausu-
la asociada a un nodo hoja no es vac´ıa pero su literal asociado ya no puede
unificarse con ninguna cl´ ausula de entrada, entonces se dice que el nodo es
un fallo.
Si bien la programaci´ on l´ogica se aplica en un creciente n´ umero de pro-
blemas pertenecientes a muy diversos dominios, tambi´en adolece de ciertas
limitaciones. Es el caso de los problemas que requieren una noci´on 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 car´acter l´ ogico de los programas. La soluci´on
no pasa por a˜ nadir caracter´ısticas no l´ ogicas a la programaci´ on l´ogica, sino
en desarrollar mejores y m´ as potentes herramientas como las l´ogicas modales
o temporales.
En este sentido se presentan las l´ ogicas temporales, ya que representan
la mejor manera de extender la programaci´on l´ ogica para modelar propie-
dades din´ amicas dependientes del tiempo como las usadas en razonamiento
temporal o simulaci´on. Existen propuestas para extender la programaci´on
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 modificationes en el algoritmo de unificaci´ 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 l´ogica temporal.
Las siguientes implementaciones est´an basadas en los conceptos m´ as sim-
ples de la l´ogica temporal b´ asica –lineal y de ramificaci´on– explicados en la
secci´ on 2.1, extendi´endolos seg´ un las necesidades de cada lenguaje.
4.1.1. Chronolog.
Chronolog fue concebido por Wedge [86, 87] como propuesta sobre la
programaci´ on l´ogica basada en cl´ ausulas de Horn antes de su materializaci´ on
definitiva 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:
first, para referirse al momento inicial en el tiempo.
next, usado para el momento siguiente.
Esta concepci´ on implica una noci´ on de movimiento a trav´es 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 prefijo 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, f´ormula compuesta de next-atoms.
cl´ausula 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.
cl´ausula permanente, an´ alogamente, cl´ausula de la forma B ⇐A
1
, . . . , A
n
donde cada B y cada A
i
son next-formulas. La diferencia con la cl´ausula
inicial es el car´ acter temporal, ya que la cl´ausula permanente implica
al operador .
Podemos definir 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 resoluci´on, 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 first a todas las cl´ausulas 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 hac´ıa 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 noci´on 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.
cl´ausula, que puede ser una cl´ausula ordinaria o la cl´ ausula siempre.
cl´ausula siempre, definida como A donde A es una cl´ ausula ordinaria.
cl´ausula ordinaria, que puede tener s´olo 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 cl´ausulas ordinarias.
cuerpo, definido como una f´ ormula at´omica, 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 m´ınima. Aunque existen conjeturas
que apuntan en la direcci´ on contraria [64].
4.1.4. Temporal Prolog de Sakuragawa.
Otra implementaci´on 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 cl´ausulas
de pograma son causales, esto es, el significado de los predicados en el futuro
depende de su significado 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 l´ogica de intervalos.
Como se describe en la secci´ on 3, la l´ ogica temporal de intervalos es una
forma de l´ogica temporal en la cual la sem´antica de las f´ormulas se define por
medio de interpretaciones temporales y pares, es decir, pares de momentos
en el tiempo que representan una duraci´on espec´ıfica. Los dos lenguajes m´as
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 unificaci´ on. Incluso incluyen algunas caracter´ısticas 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 traducci´on casi inmediata. Los operadores b´asicos 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 f´ormulas y expresiones a trav´es de and. A partir de estos elementos, un
programa Tempura es un conjunto de f´ormulas ejecutables, aunque tambi´en
existe un conjunto de operadores secundarios, definidos sobre los anteriores,
para facilitar la tarea del programador y hacer el lenguaje m´ as asequible.
Otra decisi´on de dise˜ no importante es la de eliminar la disyunci´ on ∨ y la
negaci´ on en aras de la eficiencia.
Las ejecuciones de los programas escritos para Tempura consisten en pro-
cesos de reducci´on, 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.
Tambi´en basado en la ITL e influenciado 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 cl´ausula P :- Q, R significa que Q y R son ejecuta-
dos al principio de un intervalo de tiempo de manera concurrente.
chop(&&), operador que divide un intervalo de tiempo en dos subin-
tervalos. La cl´ ausula P :- Q && R significa que Q ser´ a ejecutado al
principio del primer subintervalo y R al principio del segundo.
next(@), la cl´ ausula P :- @Q significa que Q ser´ a ejecutado en el inter-
valo de tiempo inmediatamente posterior al actual.
always(#), la cl´ ausula P :- #Q significa que Q se ejecutar´a en todos
los subintervalos que componen el intervalo de P.
sometime <>, la cl´ausula P :- <>Q significa 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 reificada. 4 PROGRAMACI
´
ON L
´
OGICA.
keep, la cl´ ausula P :- keep(Q) significa que Q ser´ a ejecutado en cada
subintervalo de P excepto en el final.
final(fin), la cl´ ausula P :- fin(Q) significa que Q s´ olo ser´ a ejecutado
en el intervalo final de P.
Los intervalos pueden ser manipulados usando determinados operadores de-
finidos en el lenguaje como length, empty y notEmpty. La ejecuci´ on de un
programa Tokio es una mezcla de resoluci´ on y reducci´on. En lo relativo a la
unificaci´ on de variables, al igual que en Tempura, ´estas pueden variar con
el tiempo, por lo que el proceso de unificaci´on es complicado y se divide en
dos tipos: uno para unificar dos valores de variables Tokio, y el otro usando
directivas especiales para unificaci´on de variables en momentos espec´ıficos.
4.3. Programaci´ on en l´ogica reificada.
Con la finalidad de completar un cat´ alogo b´ asico de opciones en progra-
maci´ on l´ogica, incluimos tambi´en dos implementaciones no basadas en los
conceptos cl´asicos de la l´ ogica temporal, de intervalos o no.
4.3.1. Temporal Prolog de Hrycej.
Hrycej tambi´en desarroll´ o una extensi´on a la que llam´ o Temporal Pro-
log [40], aunque en esta ocasi´ on no estaba basada directamente en l´ogica
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, tambi´en est´ a construido sobre
Prolog introduciendo en este caso dos tipos adicionales de cl´ ausulas:
Referencias temporales, usadas para afirmar 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 aplicaci´on de su extensi´ on la planifica-
ci´ on y consulta de bases de datos, as´ı como la potencial aplicaci´ on en f´ısica
cualitava [41].
22
4.3 Programaci´ on en l´ ogica reificada. 4 PROGRAMACI
´
ON L
´
OGICA.
4.3.2. Starlog.
Starlog es un lenguaje de programaci´on temporal capaz de manejar al-
gunos problemas en los que el tiempo tiene una papel fundamental. Al igual
que el anterior, tampoco est´a basado directamente en la l´ogica 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 defiende que, dado un dominio, la tarea de construir sobre ´el modelos
computables usando para ello la l´ogica y las ontolog´ıas es lo que conocemos
como representaci´on 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 menci´on para ilustrar la importancia, la relevancia y la ade-
cuaci´ on de los grafos para la representaci´on del conocimiento, lo que es una
aproximaci´ on habitual en Inteligencia Artificial [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, m´as 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 var´ıa un
poco, ya que es necesario expresar la noci´on 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 s´olo el paso de un
estado a otro, sino el transcurso del tiempo. Veremos a continuaci´on dos de
las construcciones m´ as habituales para almacenar la din´ amicas temporales
sobre las que posteriormente podremos verificar proposiciones.
5.1. Sistemas de transici´ on etiquetados.
Un sistema de transici´on etiquetado (LTS de sus siglas en ingl´es) es b´ asi-
camente un grafo dirigido con etiquetas en las aristas, donde los estados
equivalen a los v´ertices y las transiciones etiquetadas a las aristas con eti-
quetas. Se utilizan a menudo para definir 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 vac´ıo 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 transici´on 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, adem´as, desde el estado s
j
existe una transici´on
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 transici´on
etiquetado donde el conjunto de transiciones s´olo consta de una relaci´on
binaria simple sobre S. Este tipo de estructuras de Kripke son las usadas
en l´ogica 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 tendr´ıamos estructuras de Kripke para l´ ogica polimodal.
Formalmente, definimos 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 funci´on 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 tambi´en podemos escribir como s ← t. Dada una secuencia infinita
de estados π = 's
1
, s
2
, . . .`, definimos π(i) = s
i
y π = (s
i
, s
i+1
, . . .)∀i ∈ N.
Una secuencia infinita 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 f´ormula f es universalmente v´alida en una estructura
de Kripke M, y denotamos M [= Af, si y s´ olo si π [= f∀π ∈ M, π(0) ∈ I.
Por otra parte, es existencialmente v´alida, 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 l´ogica interpretada sobre estructuras de Kripke.
En su trabajo establecen dos m´etodos para mapear estructuras de Kripke a
sistemas de transici´ on etiquetados y viceversa, as´ı como sendas funciones de
transformaci´ on entre las dos l´ogicas preservando los valores de verdad.
Por tanto, resulta indiferente cu´al 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 adem´as ambas ca-
sos espec´ıficos de grafos etiquetados, las dos pueden ser representadas sobre
cualquiera de las bases de datos en grafo existentes. Para nuestro prop´osi-
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 l´ogicas temporales
ya ha sido satisfactoriamente probada en la resoluci´ on de problemas como
la especificaci´on y verificaci´on de programas [46, 54], el razonamiento tem-
poral [18, 73], la inteligencia artificial [76, 6] o las bases de datos tempo-
rales [22, 82, 33]. Sin embargo, aunque en este ´ ultimo campo se han hecho
grandes avances, la mayor´ıa de las aproximaciones a sistemas de consulta han
seguido las directrices del ´ algebra relacional, el lenguaje SQL, la ling¨ u´ıstica
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. Ocasi´on de m´as para pre-
guntarse qu´e 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 reci´en nombradas bases de datos NoSQL [80]
(acr´ onimo que se acerca m´as a una invitaci´on 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 generaci´on 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 fiabilidad y la replicaci´ on como los puntos centrales. En este
sentido va la queja de Michaek Stonebraker et al. cuando concluye que ((las
l´ıneas de c´odigo 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 espec´ıficas
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 inflexi´ on en el actual panorama de las bases de datos,
produci´endose el salto definitivo 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 teor´ıa de grafos. Sin embargo no son
28
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
las m´as populares, puesto que por las necesidades de los sistemas actuales
se suelen demandar otro tipo de caracter´ısticas, como las almacenes o cach´es
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 aqu´el 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 noci´on
de grafo (hipergrafos o hipernodos) [3]. Adem´as los datos se manipulan a
trav´es 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 identificadores, 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 restricci´on que coarte la libertad a
la hora de introducir los datos y las relaciones entre ellos deber´a colocarse
en una capa superior a la de la persistencia, ya que no implementan (o no
suelen implementar) tales restricciones.
En estos entornos, reflejar cualquiera de las estructuras definidas 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 creaci´on, 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
continuaci´on describimos algunas de las m´as 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 acad´emico, desde marzo de 2010
DEX es mantenida y comercializada por la compa˜ n´ıa Sparsity-Technologies
4
,
una entidad saliente de la Universidad Polit´ecnica 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´ı est´a permitida. Completamente libre
de esquema, permite la ejecuci´ on de traversals como m´etodo de consulta,
aunque no proporciona un lenguaje espec´ıfico 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 te´orica MapReduce [24].
Liberada como sofware libre bajo una licencia de tipo Apache
7
, los desa-
rrolladores del proyecto defienden 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 podr´ıa 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 modificar en
cualquier momento.
HyperGraphDB es en s´ı misma una base de datos embebida con un fra-
mework de distribuci´on basado en el protoclo XMPP
9
, que adem´as funciona
internamente con un almac´en clave-valor: una base de datos BerkeleyDB [61].
En su forma actual est´a 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 t´erminos 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 aut´onoma 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 replicaci´on, de manera que diferentes bases de datos
puedan colaborar gestionando grafos realmente grandes.
Stores Project. Proporciona una interfaz com´ un para distintas tecno-
log´ıas 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. Define una biblioteca de modelos de objetos
reusable que pueden ser utilizados como esquemas en las aplicaciones.
Con una licencia Affero GPL
12
, InfoGrid ofrece opciones de soporte comer-
cial a trav´es de la compa˜ n´ıa NetMesh
13
.
6.1.5. InfiniteGraph.
InfiniteGraph
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 s´olo requiere de un m´ınimo esfuerzo de desarrollo y dise˜ no para
que los programadores puedan construir r´ apidamente los sistemas seg´ un sus
necesidades.
La compa˜ n´ıa que se encarga de la licencia de la base de datos es Objectivity,
Inc.
15
, de la que forma parte InfiniteGraph desde el a˜ no 2010.
12
GNU Affero General Public License: http://www.gnu.org/licenses/agpl-3.0.
html
13
NetMesh: http://netmesh.us/
14
InfiniteGraph: 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 caracter´ısticas de una base de datos robusta y madura. De cara al
programador, ofrece una buena orientaci´ on a objetos y una estructura de red
flexbile, en lugar de estrictas tablas est´aticas. Sin embargo, sigue proporcio-
nando todos los beneficios 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 c´odigo abierto disponible bajo una licencia GPL v3 para
su edici´ on Community, y con ediciones Advance y Enterprise disponibles
como Affero GPL y con soporte por la compa˜ n´ıa 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 flexible 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 caracter´ısticas 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 invenvi´on 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: inserci´on r´apida y b´ usquedas aun m´as 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 t´erminos 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 espec´ıficos a una tecnolog´ıa o disposici´on de los
datos concretos. Es por ello que no podemos s´ olo describir uno s´olo 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´ afico 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 representaci´on en grafo tanto de datos y como de consul-
tas, Consens y Mendelzon definieron el lenguaje de consultas llamado Graph-
Log [23]. En GraphLog, las consultas son patrones de grafos y las aristas en
las consultas representan caminos en la base de datos.
A d´ıa de hoy no parece existir una implementaci´ on de referencia funcio-
nal y correcta. El sistema gestor de bases de datos Oracle a˜ nadi´o 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, versi´on 2.0: http://www.apache.org/licenses/LICENSE-2.0.html
34
6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.
6.2.3. Gremlin.
Basado en el ´ algebra de caminos definida en [70], Gremlin es un 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. M´as 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 t´ecnico 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 espec´ıfico.
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 gen´eticos GeneSeek. PQL incorpora muchas de las ca-
racter´ıstica de los lenguajes de consultas para datos semi-estructurados y
generaliza el lenguaje StruQL, un lenguaje de consulta tambi´en 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 curaci´on de base de datos. Estas restricciones gu´ıan
la generaci´on din´amica de planes de consulta potenciales, lo que permite que
una consulta simple permanezca siendo pr´acticamente 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 representaci´on de la informaci´on en la Web. Se
35
6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.
suele utilizar para representar, entre otras cosas, informaci´on personal, redes
sociales, metadatos sobre artefactos digitales, as´ı como para proporcionar un
medio de integraci´on sobre or´ıgenes dispares de informaci´ on. SPARQL, es el
lenguaje de consulta para RDF, est´ a dise˜ nado para reunir los casos de uso
y requisitos identificados por el grupo de trabajo de RDF Data Access. El
lenguaje est´ a relacionado ´ıntimamente a las siguientes especificaciones:
La especificaci´ on del Protocolo SPARQL para RDF (SPORT) que de-
fine el protocolo remoto para efectuar consultas SPARQL y recibir los
resultados.
La especificaci´on SPARQL Query Results XML Format (RESULTS)
que define el formato de un documento XML para representar los re-
sultados de las consultas SPARQL SELECT y ASK.
6.2.6. UnQL/UnCAL.
UnQL es una propuesta de lenguaje de consulta sobre datos semi-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 ficheros XML pero defininiendo mecanismos para evitar
entrar en bucles infinitos durante la evaluaci´ on. El ´ algebra interna de UnQL
se denomina UnCAL y define el concepto de recursi´on 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 gen´erica.
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 id´entico nombre
21
desarrollado por
la compa˜ n´ıa de reciente aparci´ on Couchbase
22
para consultar bases de datos
semi-estructuradas, ficheros 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. L´ogica temporal de intervalos y consulta
de grafos.
Una vez definidos todos los conceptos necesarios, pasaremos a mostrar
c´ omo a partir de ´estos es posible traducir autom´ aticamente desde una pro-
posici´on expresada en un lenguaje temporal a la correspondiente expresi´ on
en lenguaje de consulta de grafos. A modo de aproximaci´ on se usar´an 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 finales no estar´an marcados de ma-
nera alguna debido a que la longitud de cada camino a verificar 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 reflejar las primeras en los segundos. De esta manera, si
volvemos a la definici´on de la secci´on 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 relaci´on 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 L´ogica 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 qu´e propiedades est´ an en cada no-
do, es decir, mantiene los valores de los ´atomos en cada estado. En
la pr´actica esta funci´ on es innecesaria ya que los nodos mantienen la
informaci´ on sobre sus atributos de manera interna.
7.2. L´ogica 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 ser´ıa expresado como v = g.v(0) en Gremlin.
Definimos adem´as 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 aritm´eticas. 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, entendi´ense 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 ser´a tarea del lector efectuar los
cambios necesarios para que su proposici´on 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 ser´a un
valor num´erico, un valor l´ogico o, en su defecto, una cadena de carac-
teres.
Las funciones que implican variables se eval´ uan usando la aritm´etica
nativa de los lenguajes.
38
7.2 L´ogica temporal sobre lenguaje de consultas para grafos.
7 L
´
OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE
GRAFOS.
Operador ((siguiente)) (next): ahora toma el significado 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
est´e etiquetada, para as´ı dejar la puerta abierta a futuras relaciones
como previous, que podr´ıan 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 definidas re-
laciones como ≤ en el lenguaje de consultas.
La igualdad se har´ a conforme a los operadores l´ ogicos definidos 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 conjunci´on, ya que la negaci´ on puede obtenerse
modificando las f´ ormulas y proposiciones para producir el resultado
opuesto, esto es, cambiar = por =, < por ≥, y > por ≤.
Operador ((siempre)) (always): se interpretar´ a como f´ormulas que se
deben verificar en todos los nodos a partir de aqu´el en el que sea es-
tablecido el operador. Independientemente del resto de proposiciones
asociadas al nodo, la condici´on 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 est´an basados en pattern matching, por lo que la definici´ 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 patr´on definido se devuelve y se sigue inspeccionando el
grafo. Por tanto, la tarea de conversi´ on consiste en realidad en transformar la
proposici´ on l´ogica en un patr´ on que pueda ser buscado en el grafo, de ah´ı que
definamos la sintaxis anterior y podamos incluso extender nuevos operadores
como veremos en la secci´ on 7.2.3.
39
7.2 L´ogica 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 ser´ıa v´ alida en el grafo de la figura 1, pero no lo ser´ıa en el de la figura
2, ambos inspirados tambi´en en la definici´ 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 L´ogica 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 tambi´en ser´ an
tenidas en cuenta en nuestra analog´ıa 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 est´e contenida en una proposici´ on o f´ormula que
implique operadores temporales.
´
σ
w = true ser´ a cierto si la f´ ormula no se cumple en el grafo.
Como mencionamos en la secci´on 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 especificar, esta vez, sobre grafos con un s´ olo nodo.
En la pr´actica, no contemplar el nodo inicial no tendr´a 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 tambi´en pueden ser definidos 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 finales lo ser´ an so-
bre el ´ ultimo nodo del posible camino, identificado tras contabilizar el n´ umero
m´ aximo de operadores next anidados que se tenga en la proposici´ on.
´
σ
w = true. Para definir 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 tambi´en se
evaluar´a 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 l´ogicas del lenguaje.
Para la implicaci´ on habr´ a que hacer uso de su definici´ on en base a la
negaci´ on y la conjunci´ on y, a su vez, usar la negaci´ on como el ope-
rador l´ogico comparativo opuesto. Por simplicidad, el operador ∨ s´ olo
podr´a ser usado dentro de f´ ormulas y no para componer proposiciones
41
7.2 L´ogica temporal sobre lenguaje de consultas para grafos.
7 L
´
OGICA TEMPORAL DE INTERVALOS Y CONSULTA DE
GRAFOS.
que impliquen operadores temporales, ya que esto implicar´ıa produ-
cir un ´ arbol de consultas por cada ocurrencia de la 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 construir´a 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 interpretaci´on infor-
mal de gets como ((llega a ser)), o ((se convierte en)). Por tanto, habr´ a que
evaluar si en cada nodo siguiente a aqu´el en que se tenga e
i
, se tiene
adem´ as e
j
.
stable e evaluar´a 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
). N´otese 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 final, teniendo en cuenta
la consideraci´on inicial sobre los nodos finales.
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 l´ogica 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 conversi´on lo denominaremos Pyticli
(Python Temporal Intervals Common Language Interface).
El lenguaje de programaci´on 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 f´acilmente ampliable con m´odulos externos denominados
paquetes. Algunos de ellos se incluyen en la distribuci´on est´ andar de Python
de los distintos sistemas operativos. Uno de estos paquetes habituales es
ast
25
, acr´ onimo ingl´es 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 m´etodos para parsear,
compilar y ejecutar c´odigo.
´
Esta es la pieza angular de Pyticli. Tomando una
expresi´ on sint´ acticamente correcta en Python que represente una proposici´ on
temporal, la obtenci´on del ´arbol asociado es directa mediante el m´etodo
ast.parse, por lo que la construcci´on 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 simplificar el algoritmo encargado de procesar el ´arbol de
sintaxis, el conjunto de operadores y expresiones v´ alido es el m´as limitado
posible.
Constantes. Necesarias para disponer que una proposici´on sea cierta o
falsa, nuestro lenguaje cuenta con las constantes l´ogicas true y false,
adem´ as de cualquier construcci´ on num´erica v´alida y cadenas de carac-
teres, aunque estas ´ ultimas no ser´ an utilizadas de momento. Ser´ an por
tanto constantes v´alidas 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 definen varibles en Python. Son ´atomos v´alidos J,
mi variable, propiedadCamelCase y propiedadCon1y2numeros; e
inv´ alidos 1variable y ~ nCaracterNoValido.
Operadores aritm´eticos. Los operadores definidos 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 l´ogicos. El ´ unico operador l´ogico permitido es la disyunci´on,
and.
Operadores temporales. S´olo dos operadores temporales b´ asicos est´ an
definidos, next y always, con la correspondiente sem´antica ya discutida
en secciones anteriores.
Expresiones. Entenderemos como expresiones cualquier operaci´ on aritm´eti-
ca sobre ´ atomos y constantes que no implique operadores temporales.
Proposiciones. Una proposici´ on ser´a una composici´ on de operadores
l´ ogicos, expresiones y operadores temporales. De esta manera next(J==1
and always(I<=2)) ser´ a una expresi´on no v´ alida que tendr´ıa que ser
expresada como next(J==1) and next(always(I<=2)).
Tambi´en estar´ a permitido modificar la precendecia asociada a los operadores
utilizando para ello los s´ımbolos de par´entesis ( y ).
Una gram´atica aproximada podr´ıa ser la definida 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 v´alida.
8.2. Limitaciones.
Existen ciertas limitaciones que han de ser tenidas en cuenta. La m´ as
importante es que la finalidad de esta conversi´ on no es generar un grafo que
verifique la proposici´ on, sino, dada una proposici´ on y un grafo, comprobar si
se verifica la proposici´on 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 s´ımbolos al
conjunto m´as b´asico posible, en resumen, a los operadores ∧, =, next y
always. Menci´on especial require la ausencia del operador (negaci´ on), que
podr´ıa 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 secci´on 8.5 se indicar´ an
algunas pautas ´ utiles a seguir en pos de una posible implementaci´ on.
45
8.3 Algoritmo de conversi´on. 8 LENGUAJE PYTICLI.
8.3. Algoritmo de conversi´ on.
El proceso mediante el cual a partir de una proposici´on se devuelve una
consulta sobre grafos consta de varias partes. A grandes rasgos vendr´ıa descri-
to por el algortimo 1. Dado que la funci´on AbstractSyntaxTree es invocada
directamente a trav´es del m´etodo parse del paquete de Python ast que pro-
duce el ´ arbol de sintaxis correspondiente, el peso de la conversi´on 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 cu´al deben cumplirse las expresiones que tenga definidas 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 tambi´en 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 verificar en cada uno de ellos.
Ambas estructuras usan una representaci´on abstracta para los ´ atomos y las
constantes: los n´ umeros son encerrados entre los s´ımbolos ¦# 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 refieren 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 conversi´on. 8 LENGUAJE PYTICLI.
Por su parte, los operadores tambi´en son transformados a su representaci´on
por convenio, esto es, & para el operador disyunci´on, == 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 conversi´on: 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 funci´on GenerateQuery manipular´ a los s´ımbolos 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 generaci´on
de la consulta del parseo del ´arbol sint´ actico.
Como se aprecia, el n´ ucleo de funcionamiento de Pyticli es la funci´on
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 m´etodos 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 operaci´on.
Lo que es distinto de, por ejemplo, las operaciones l´ogicas o booleanas (clase
ast.BoolOp), que tienen parte izquierda, y una lista con los comparadores y
los t´erminos implicados.
Como es habitual, el tratamiento del ´ arbol sint´actico 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 conversi´on. 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 conversi´on. 8 LENGUAJE PYTICLI.
always, next y las constantes) para luego, al terminar cada llamada recur-
siva, invocar a un m´etodo de reducci´on 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 verificar 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 extra´ıda se corresponde con una expresi´ on v´ alida, en cuyo
caso puede tomar dos decisiones:
La expresi´ on es una operaci´ on aritm´etica, en cuyo caso simplemente se
a˜ nade como un elemento at´omico en la pila.
La expresi´ on es una operaci´ on l´ogica, por lo que deber´a 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 l´ogicas s´olo usan el
operador ∧, pero se deja la puerta abierta para soportar la disyunci´on.
Si no encuentra una expresi´ on v´ alida que formar con los primeros 3 elementos
de la pila, entonces devuelve la pila sin modificar.
El proceso anterior est´ a tambi´en apoyado en una bater´ıa de funciones
y m´etodos auxiliares de los que hay que destacar la funci´on StackSplit,
encargada de inspeccionar la pila en busca de llamadas anidades de los
operadores always y next, identificando a partir de qu´e 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 ejecuci´on se tiene que la pila
s = 'next, always, next, next, expr`, ser´a equivalente a tener siempre expr a
partir del estado 3. Sin embargo, aunque esta asunci´on puede resultar tri-
vial, no ha sido posible localizar una demostraci´on v´alida que la sustente en
la literatura relacionada, salvo, quiz´as, algunas nociones parecidas aunque in-
completas en [10]. Por tanto, queda su demostraci´on formal emplazada como
trabajo futuro.
49
8.3 Algoritmo de conversi´on. 8 LENGUAJE PYTICLI.
Algorithm 3 Algoritmo de reducci´on 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 coment´o en la secci´ on 1, el presente proyecto no pretende ser
una soluci´ on para verificaci´ 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 verificadas (satisfactibles). Esto
permitir´ıa, 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 cat´alogo de ejemplos
de [60], se muestran a continuaci´on algunas de las correspondencias entre
f´ ormulas expresadas en ITL y sus equivalentes en Pyticli.
8.4.1. Operadores b´asicos.
Las primeras f´ormulas de ITL sint´acticamente 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 b´asicas en Pyticli a partir de
la original expresada en ITL, ya que la ´ unica consideraci´ on a tener en cuenta
es la negaci´on, qu´e s´ olo puede aplicarse a las comparaciones. Por tanto, la
f´ ormula (23) no tendr´ıa ning´ un equivalente posible, ya que, como vimos en
la secci´on 8.5, implicar´ıa la noci´on 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: implicaci´on. Aplicando las construcciones l´ogicas convencio-
nales para la conjunci´on y la implicaci´ on, podemos reescribir la f´ormula
(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 f´orumla (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 est´a 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 v´ıas para
solventar estas limitaciones.
52
8.5 Mejoras al lenguaje. 8 LENGUAJE PYTICLI.
8.5.1. Operadores y ∨.
Actualmente, para hacer uso de la negaci´on es necesario que el usuario
de Pyticli prepare primero su proposici´on y expanda las negaciones que en-
cuentre en sus expresiones con los correspondientes operadores negados. De
esta manera, usando el ´ algebra de Boole, habr´ıa que obtener las equivalencias
sustituyendo donde proceda == por !=, != por ==, < por >=, y <= por >, > por
<=, y >= por <. Este procedimiento podr´ıa automatizarse dentro de la funci´on
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, finalmente, apilar la nueva expresi´ on. Un
mecanismo parecido podr´ıa seguirse para el operador conjunci´ on ∨.
Sin embargo conviene resaltar que con el procedimiento descrito s´ olo ser´ıa
posible utilizar la negaci´ on y la conjunci´on en expresiones que no impli-
quen operadores temporales. Esto es, al encontrar una expresi´ on del ti-
po not(next(J==2)), nuestra propuesta funcionar´ıa correctamente, pero en
cambio no resolver´ıa correctamente expresiones del tipo not(next(J==2)
and always(I==1)), ya que not(always(I==1)), que ser´ıa equivalente 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´ı ser´ıan f´acilmente
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 f´acilmente
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 m´etodo generate cuyo ´ unico par´ametro es el valor l´ogico
verbose. Esta clase proporciona en la variable self.states una lista con
las expresiones a satisfacer en cada estado convenientemente abstra´ıdas y
tras haber procesado los operadores temporales.
53
8.5 Mejoras al lenguaje. 8 LENGUAJE PYTICLI.
Como se aprecia en el extracto de c´odigo 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 funci´on 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, adem´as, 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 par´ametros, el primero especifica 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 est´a disponible la base de datos Neo4j a trav´es de
su cliente REST para Python
26
. Una vez que la conexi´ on es estableci-
da, cada conversi´ on de proposici´on 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. S´olo una conexi´on 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 par´ametros imprime la ayuda general de la consola. Acom-
pa˜ nado de otro comando muestra la ayuda espec´ıfica de ´este.
exit, para terminar la sesi´on de la consola.
Una sesi´ on habitual de la consola puede ser la mostrada en 8.6 (el s´ımbolo
:> simboliza la entrada o prompt de la consola).
$ python shell.py
Pyticli 0.0.3 by Javier de la Rosa.
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 c´odigo 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
. Adem´as, 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 ser´ıa 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 l´ogica 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 representaci´on 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, ser´ıa interesante estudiar en profundiad las similitudes
entre el ´ algebra de caminos y las construcciones en l´ogica temporal, as´ı como
los modelos de Herbrand [83] para una posible implementaci´ on general del
m´etodo que pueda extenderse a un lenguaje de consultas te´ orico sobre la
l´ ogica temporal.
58
REFERENCIAS
10. Bibliograf´ıa.
Referencias
[1] M. Abadi & Z. Manna. Temporal logic programming. In Proceedings of the
1987 Symposium on Logic Programming, 4–16. IEEE Computer Society
Press, 1987.
[2] M. Abadi & Z. Manna. Temporal logic programming. Journal of Symbolic
Computation, 8:277–295, 1989.
[3] R. Angl´es & C. Guti´errez. 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 Programming’85, 221:138–147.
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 Artificial 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 PDK’91: International
Workshop on Processing Declarative Knowledge, volume 567 of LNAI,
pages 365–382. Springer-Verlag, 1991.
[8] P. Balbiani, A. Herzig, & M. Lima-Marques. Implementing Prolog ex-
tensions: a parallel inference machine. In Proc. of the 1992 International
Conference on Fifth Generation Computer System, pages 833–842. ICOT,
1992.
[9] R. Bayer & E. M. McCreight. Organization and Maintenance of Large
Ordered Indices. In Acta Informatica, 1: 173–189. 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 finite Krip-
ke structures in propositional temporal logic, In Theoretical Computer
Science, 59(1–2): 115–131, 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): 76–110. Springer, 2000.
[14] J. P. Burgess. Basic tense logic. In D. M. Gabbay and F. Guethner, edi-
tors, Handbook of Philosophical Logic, 2(89): 89–134. D. Reidel 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, 384–390,
Milwaukee, Wisconsin, 1981.
[17] M. Chein & M. L. Mugnier. Simple Conceptual Graphs, Graph-based
Knowledge Representation, series Advanced Information and Knowledge
Processing, 59–81, Springer London, 2008.
[18] E. Chouraqui. Formal expression of time in a knowledge base. In P.
Smets, A. Mamdani, D. Dubois, and H. Prade, editors, Non-Standard
Logics for Automated Reasoning, pages 81–103. Academic Press, 1988.
[19] E. M. Clarke, D. E. Long & K. L. McMillan. Compositional model chec-
king. In Logic in Computer Science, 1989. LICS’89, Proceedings., Fourth
Annual Symposium on, 353–362. IEEE, 1989.
[20] E. Clarke. Model checking. In Foundations of software technology and
theoretical computer science, 54–56. 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):214–254, 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, 404–416. ACM, New York, NY, 1990.
[24] J. Dean S. Ghemawat. MapReduce: simplified data processing on large
clusters, In Commun. ACM 51(1): 107–113, 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 Benefits of Graph Databases. OSCON pre-
sentation, 2009. Accesed on July 2011: http://www.slideshare.net/
emileifrem/neo4j-the-benefits-of-graph-databases-oscon-2009.
[27] J. Ellis. NoSQL Ecosystem. 2009. Accesed on July 2011: http://www.
rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/.
[28] E. A. Emerson & C.-L. Lei. Modalities for model checking: Branching
time strikes back. Science of Computer Programming, 8:275–306. 1986.
[29] J. L. Fern´ andez Vindel, A. Manjarr´es Riesco & F. J. D´ıez Vegas. L´ogica
Computacional. Dpto. Inteligencia Artificial, 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, 197–237. Academic Press,
1987.
[32] D. M. Gabbay. A temporal logic programming machine [modal and tem-
poral logic programming, Part 2]. Department of Computing, 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 423–430,
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, 91–119. 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: 278–291, 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: 278–291, in the series
Lecture Notes in Computer Science, Springer Verlag, Berlin, 1983.
[38] T. H¨arder & A. Reuter. Principles of Transaction-Oriented Database
Recovery. In ACM Computing Surveys 15(4): 287–317. 1983.
[39] D. Harel, D. Kozen & R. Parikh. Process logic: Expressiveness, decida-
bility, completeness. In Journal of Computer and System Sciences, 25(2):
144–170, 1982.
[40] T. Hrycej. Temporal Prolog. In Proc. of the European Conference on
Artificial Intelligence, 296–301, Munich, Germany, 1988.
[41] T. Hrycej. A temporal extension of Prolog. Journal of Logic Program-
ming, 15: 113–145, 1993.
[42] G. Klyne & J. Carroll. Resource Description Framework (RDF) Con-
cepts and Abstract Syntax. Accessed on July 2011: http://www.w3.org/
TR/2004/REC-rdf-concepts-20040210/
[43] R. Kowalski & D. Kuehner. Linear Resolution with Selection Function
Artificial Intelligence 2: 227-60, 1971.
62
REFERENCIAS REFERENCIAS
[44] R. A. Kowalski. Predicate logic as programming language. In Proceedings
of IFIP’74, 569–574, Amsterdam, 1974.
[45] S. Kripke. Semantical considerations on modal logic. In Acta philosop-
hica fennica, 16(1963): 83–94. 1963.
[46] F. Kroger. Temporal Logic of Programs. Springer-Verlag, Berlin Heidel-
berg, 1987.
[47] G. M. Kuper & M. Vardi. The Logical Data Model. In ACM Transac-
tions on Database Systems (TODS) 18(3): 379–413, 1993
[48] N. Leavitt. Will NoSQL databases live up to their promise?. In Compu-
ter, 43(2): 12–14. IEEE, 2000.
[49] U. Leser. A query language for biological networks. Bioinformatics 21(2):
33–39. 2005.
[50] M. Levene & A. Poulovassilis. An Object-Oriented Data Model Forma-
lised Through Hypergraphs. Data & Knowledge Engineering (DKE) 6(3):
205–224, 1991.
[51] S. Litt. ”NoSQL: The Unix Database (With awk)”. Linux 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 finding paths in graphs. In Procee-
dings of the International Conference on Information Technology Interfa-
ces, 1: 657–662. 2004.
[54] Z. Manna & A. Pnueli. Verification of concurrent programs: the tem-
poral framework. In Boyer and Moore, editors, Correctness Problem in
Computer Science, pages 215–273. Academic Press, 1981.
[55] N. Mart´ınez-Bazan, V. Munt´es-Mulero, S. G´omez-Villamor, J. Nin, M.
S´ anchez-Mart´ınez & 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:83–96, 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 STAN–CS–83–970.)
[59] B. Moszkowski. A temporal logic for multilevel reasoning about hard-
ware. Computer 18, 2: 10–19, 1985.
[60] B. Moszkowski. Executing Temporal Logic Programs. Cambridge Univer-
sity Press, 1986.
[61] M. A. Olson, K. Bostic & M. Seltzer. Berkeley db. In Proceedings of the
FREENIX Track: 1999 USENIX Annual Technical Conference, 183–192,
1999.
[62] M. A. Orgun & W. W. Wadge. Chronolog: A temporal logic program-
ming language and its formal semantics. Department of Computer Science,
University of Victoria, Victoria, B.C., Canada, 1988.
[63] M. A. Orgun & W. W. Wadge. Theory and practice of temporal lo-
gic programming. In Intensional Logics for Programming, 23–50. Oxford
University Press, 1992.
[64] M. A. Orgun & W. Ma. An Overview of Temporal and Modal Logic
Programming. In Temporal Logic, pages 445–479. 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):
513–532. IEEE, 1995.
[66] A. Papantonakis & P. H. J. King. Syntax and Semantics of Gql, a Grap-
hical Query Language, In Journal of Visual Languages & Computing, 6(1):
3–25, 1995.
64
REFERENCIAS REFERENCIAS
[67] R. Pointer, N. Kallen, E. Ceaser & J. Kalucki. Introducing FlockDB.
Accesed on July 2011, http://engineering.twitter.com/2010/05/
introducing-flockdb.html
[68] E. Prud’hommeaux & A. Seaborne. SPARQL query language for RDF.
Tech. rep., World Wide Web Consortium, 2004. Accessed on July 2011
http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/
[69] L. Richardson & S. Ruby. RESTful Web Services. 2007. O’Reilly Media,
Inc.
[70] M. A. Rodriguez, J. Shinavier. Exposing Multi-Relational Networks to
Single-Relational Network Analysis Algorithms, Journal of Informetrics,
4(1): 29–41. Elsevier, LA-UR-08-03931, 2009.
[71] D. W. Rolston. Chronolog: A pure tense-logic-based in nite-object pro-
gramming language. Department of Computer Science and Engineering,
Arizona State University, Tempe, Arizona, August 1986.
[72] D. W. Rolston. Chronolog: A pure tense-logic-based in nite-object pro-
gramming language. Department of Computer Science and Engineering,
Arizona State University, Tempe, Arizona, August 1986.
[73] F. Sadri. Three approaches to temporal reasoning. In A. Galton, editor,
Temporal Logics and Their Applications, pages 121–168. Academic Press,
1987.
[74] T. Sakuragawa. Temporal Prolog. In Proc. of RIMS Conference on Soft-
ware Science and Engineering. Springer-Verlag, 1987.
[75] B. Schneider. Red black trees, In Dr. Dobb’s Journal, 17(4): 42–46. 1992.
[76] P. Smets, A. Mamdani, D. Dubois, & H. Prade, editors. Non-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(2–5): 75–93, 1992.
65
REFERENCIAS REFERENCIAS
[79] M. Stonebraker. SQL databases v. NoSQL databases. In Communica-
tions of the ACM, 53(4): 10–11. ACM, 2010.
[80] C. Strauch. NoSQL Databases, Selected Topics on Software-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, 1–38, 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 13–23, Brisbane, Australia, August 13–16 1990.
Morgan Kaufmann Publishers Inc., Los Altos, California.
[83] M. H. Van Emden & R. A. Kowalski. The semantics of predicate 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 verification. In Proceedings of the First Symposium on Logic in
Computer Science, 322–331, Cambridge, 1986.
[85] M. Vardi. An automata-theoretic approach to linear temporal logic, 238–
266. In Logics for concurrency, Springer, 1996.
[86] W. W. Wadge. Tense logic programming: a respectable alternative. De-
partment of Computer Science, University of Victoria, Victoria, B.C., Ca-
nada, 1985.
[87] W. W. Wadge. Tense logic programming: a respectable alternative. In
Proceedings of the 1988 International Symposium on Lucid and Intensio-
nal Programming, 26–32, Sidney, B.C., Canada, 1988.
66

Sign up to vote on this title
UsefulNot useful