Professional Documents
Culture Documents
INDICE
INDICE
Indice
1. Introducci on. 6
1.1. Model Checking. . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Estructura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. L ogica Modal. 9
2.1. L ogica Temporal. . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. L ogica Temporal de Intervalos. 11
3.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Satisfactibilidad. . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Interpretacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Programaci on Logica. 16
4.1. Programaci on en l ogica temporal. . . . . . . . . . . . . . . . . 18
4.1.1. Chronolog. . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2. Templog. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Temporal Prolog de Gabbay. . . . . . . . . . . . . . . . 19
4.1.4. Temporal Prolog de Sakuragawa. . . . . . . . . . . . . 20
4.2. Programaci on en l ogica de intervalos. . . . . . . . . . . . . . . 20
4.2.1. Tempura. . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Tokio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Programaci on en l ogica reicada. . . . . . . . . . . . . . . . . 22
4.3.1. Temporal Prolog de Hrycej. . . . . . . . . . . . . . . . 22
4.3.2. Starlog. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Representaci on del conocimiento. 24
5.1. Sistemas de transicion etiquetados. . . . . . . . . . . . . . . . 24
5.2. Estructuras de Kripke. . . . . . . . . . . . . . . . . . . . . . . 25
5.3. Consideraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Bases de Datos en Grafo. 28
6.1. Bases de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. DEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. FlockDB. . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.3. HyperGraphDB. . . . . . . . . . . . . . . . . . . . . . 30
3
INDICE
INDICE
6.1.4. InfoGrid. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.5. InniteGraph. . . . . . . . . . . . . . . . . . . . . . . . 32
6.1.6. Neo4j. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.7. OrientDB. . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2. Lenguajes de consulta. . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1. GQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.2. GraphLog. . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.3. Gremlin. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.4. PQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.5. SPARQL. . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.6. UnQL/UnCAL. . . . . . . . . . . . . . . . . . . . . . . 36
7. L ogica temporal de intervalos y consulta de grafos. 37
7.1. Estructuras de Kripke sobre bases de datos grafo. . . . . . . . 37
7.2. L ogica temporal sobre lenguaje de consultas para grafos. . . . 38
7.2.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.2. Satisfactibilidad. . . . . . . . . . . . . . . . . . . . . . 39
7.2.3. Interpretacion. . . . . . . . . . . . . . . . . . . . . . . 41
8. Lenguaje Pyticli. 43
8.1. Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2. Limitaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3. Algoritmo de conversi on. . . . . . . . . . . . . . . . . . . . . . 46
8.4. Aplicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4.1. Operadores b asicos. . . . . . . . . . . . . . . . . . . . . 51
8.4.2. Operadores compuestos. . . . . . . . . . . . . . . . . . 52
8.5. Mejoras al lenguaje. . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.1. Operadores y . . . . . . . . . . . . . . . . . . . . . 53
8.5.2. Operadores temporales. . . . . . . . . . . . . . . . . . . 53
8.5.3. Lenguajes de salida. . . . . . . . . . . . . . . . . . . . 53
8.6. Consola interactiva. . . . . . . . . . . . . . . . . . . . . . . . . 55
9. Conclusiones y trabajo futuro. 58
10.Bibliografa. 59
4
Indice de guras
1. Grafo de estados con varios caminos posibles. . . . . . . . . . 40
2. Grafo de estados simple. . . . . . . . . . . . . . . . . . . . . . 40
List of Algorithms
1. Algoritmo general de conversi on: Pyticli . . . . . . . . . . . 47
2. Algoritmo de procesado del AST: ProcessTree . . . . . . . . 48
3. Algoritmo de reducci on de pila: StackReduce . . . . . . . . . 50
5
1 INTRODUCCI
ON.
1. Introducci on.
Este trabajo presenta las analogas entre la l ogica modal proposicional
temporal (en adelante l ogica temporal) y el dominio de la teora de grafos.
Los actuales lenguajes temporales, basados en el correpondiente sustrato
te orico, est an ideados para generar estructuras y conjuntos de estados que
satisfagan proposiciones dadas, de manera que se pueda denir y caracterizar
un determinado sistema (formalmente, modelo) a partir del comportamien-
to esperado de este a lo largo del tiempo. Esto es especialmente util en la
denici on de modelos concurrentes. Recientemente, la Association for Com-
puting Machinery (ACM) concedio el Premio Turing a los creadores de un
mecanismo autom atico de vericaci on de estos modelos
2
, tecnica que recibe
el nombre de model checking.
La aproximaci on que aqu se presenta est a a camino entre el model checking
y los lenguajes temporales. La nalidad ultima de este trabajo es proporcio-
nar un marco practico sobre el cual poder vericar proposiciones especcas
de un sistema seg un su comportamiento. Para ello suponemos que cada vez
que el sistema cambia de un estado a otro, una traza conteniendo los valores
de cada variable es almacenada en una base de datos en grafo, de manera que
se establezca una arista dirigida entre cada dos estados si desde un estado
i
se ha pasado a otro
j
. El utilizar bases de datos en grafo para almacenar
esta informaci on es crucial ya que de esta manera se proporciona no solo un
metodo de almacenamiento ecaz, robusto, masivo y colaborativo, sino un
mecanismo para realizar consultas sobre los datos a traves de los lenguajes
nativos que implementan. Proponemos, en este sentido, un lenguaje capaz de
traducir proposiciones de l ogica temporal a consultas sobre bases de datos en
grafo, eliminando la complejidad inherente de la tecnica de model checking.
2
Researchers Created Model Checking Technique for Hardware and Software Designers:
http://www.acm.org/press-room/news-releases/turing-award-07/
6
1.1 Model Checking. 1 INTRODUCCI
ON.
1.1. Model Checking.
Si denimos el proceso mediante el cual, dado un sistema de estados, es ne-
cesario averiguar si un cierto conjunto de proposiciones se verica, tendramos
lo que se conoce como model checking [20]. Esta tecnica se emplea tanto en
sistemas hardware como software, y ha demostrado ser especialmente util en
comparaci on con otras como la simulaci on o el razonamiento, en sistemas
paralelos y concurrentes [19].
La potencia de este metodo radica en que utiliza una representacion simboli-
ca del espacio de estados, por lo que no debe enfrentarse a limitaciones de
espacio fsico de almacenamiento. A traves del -C alculo y una l ogica tem-
poral especca (CTL) es capaz de manipular formulas y relaciones y decidir
sobre la satisfactibilidad de f ormulas expresdas en l ogica temporal lineal, evi-
tando as el problema conocido como explosion de estados se conoce como
explosion de estados al incremento exponencial de estados que se da al inten-
tar vericar un sistema concurrente. Este problema releg o en un principio la
vericaci on automatica a sistemas peque nos y fue el origen del model chec-
king; pero con la aparici on de los nuevos sistemas de bases de datos en grafo,
capaces de escalar ecientemente, la cantidad maxima de estados posibles en
un sistema se incrementa de nuevo, pudiendo ahora esta tecnica ser aplicada
en maquinas de caractersticas sencillas y asequibles.
A posteriori, el algoritmo de conversi on de proposiciones de logica temporal
a consultas sobre grafos ha resultado tener ciertas similitudes al empleado en
model checking para -C alculo, incluso sin haber sido inspirado en el.
1.2. Estructura.
Tras una primera presentaci on de las l ogicas modales y un posterior anali-
sis y denici on de las logicas temporales, se muestran algunas de las distintas
implementaciones que se han ido desarrollando a lo largo del tiempo, pasan-
do desde las basadas exclusivamente en Prolog o Lisp [7, 8] hasta lenguajes
completos con sintaxis propia desarrollados en C [60].
La siguiente seccion hace una breve introduccion a las bases de conocimien-
to entendidas en el marco de la programaci on lineal y los sistemas deductivos
7
1.2 Estructura. 1 INTRODUCCI
ON.
e inductivos. El estudio se centra especcamente en los Sistemas de Tran-
sici on Etiquetados, usados en la logica temporal basada en acciones, y las
estructuras de Kripke, que sustentan la l ogica temporal basada en estados.
Ambas construcciones son, como veremos, formas particulares de grafos.
Un apartado dedicado a la denicion de las bases de datos basadas en
grafo, que vienen a integrar el grupo de las recien nombradas NoSQL (que
conviene no confundir con el gestor de bases de datos de identico nombre [51])
tambien es presentado. Tras numerar algunas de las m as conocidas de estas
bases de datos, se introducen a continuaci on los lenguajes sobre los que se
construyen las consultas y que resultan indispensables en cualquier base de
datos.
Por ultimo discutiremos c omo esta aproximaci on entre ambos mundos pue-
de repercutir positivamente de cara a decidir sobre las proposiciones tempora-
les cuyos atomos forman parte de un grafo masivo almacenado ecientemente
en disco. Los ultimos apartados se dejan para las conclusiones y el posterior
trabajo futuro.
8
2 L
OGICA MODAL.
2. Logica Modal.
Las l ogicas modales forman parte de las logicas formales y amplan su
dominio para incluir el estudio de propiedades dependientes del contexto
modalidad tales como necesidad y posibilidad [10, 11]. Para ello hacen uso
de dos nuevos smbolos que a naden a los ya existentes en el vocabulario de la
l ogica proposicional a la que extienden, estos son para denotar necesidad,
es necesario que; y para posibilidad, es posible que. Quedando adem as
denidos cada uno en funcion del otro como se muestra en (1 , 2).
p = q (1)
p = q (2)
Existe pues una clara analoga con los cuanticadores en la l ogica de
primer orden, donde se tiene (3, 4).
x (x) = x(x) (3)
x (x) = x(x) (4)
La regla de inferencia m as habitual en la logica modal es la necesita-
cion (5), y junto al modus ponens de la logica proposicional permiten denir
distintos tipos de sistema.
(5)
Cada sistema est a basado en unos axiomas y dependiendo de cuales y
cu antos utilice sera posible demostrar un mayor o menor n umero de teo-
remas. As, partiendo del axioma m as basico, denominado K (6) en honor
a Samuel Kripke [45], podemos a nadir distintos axiomas obteniendo cada
vez un sistema distinto sobre el que aplicar una interpretacion. Los axiomas
de K tambien incluyen todas las instancias de las tautologas de la l ogica
proposicional.
( ) ( ) (6)
(7)
De manera que las reglas para una K-prueba son:
9
2.1 Logica Temporal. 2 L
OGICA MODAL.
Modus ponens. Dados y = , se tiene .
Sustitucion (uniforme). Dado se tiene , donde se obtiene a partir
de reemplazando uniformemente los atomos de la proposicion en
por f ormulas arbitrarias.
Generalizacion. Dado , se tiene .
Si denimos como estructura relacional la tupla 'W, R
1
, . . . , R
k
` tal que W
es un conjunto no vaco y cada R
i
es una relacion sobre W, podemos denir
una interpretaci on o modelo como la tupla = 'F, v`, donde:
T es un marco denido por la tupla 'W, R` y donde:
W es un conjunto no vaco de elementos que reciben el nombre de
mundos posibles.
R es una relaci on entre los mundos posibles denominada relacion
de accesibilidad. La relacion de accesibilidad puede ser reexiva,
transitiva, eucldea y/o simetrica, lo que permite obtener los dis-
tintos tipos de sistemas.
v es un asignaci on en un marco T = 'W, R` y viene dada por la fun-
ci on que asocia a cada smbolo proposicional el subconjunto de mundos
donde es verdadera.
2.1. Logica Temporal.
La logica temporal [14, 72] puede verse como una instancia de la logica
modal en la que el conjunto de mundos posibles representa una colecci on
de instantes o momentos en el tiempo [64]. A nade dos nuevos operadores
existenciales a la l ogica modal proposicional, cuyas lecturas son [29]:
'P`, se satisface en alg un momento del pasado (Past).
'F`, se satisface en alg un momento del futuro (Futuro).
Tambien son habituales los correspondientes duales, que tienen car acter uni-
versal:
[H] = 'P`, siempre ha sido (Has been) satisfecha en el pasado.
Es decir, no existe un momento en el pasado en que no se satisfaga.
10
3 L
w = true (11)
12
3.4 Interpretaci on. 3 L
e e
(14)
w w
(15)
El listado de deniciones es el que sigue:
V =
0
V , donde V es una variable. Es decir, el valor de una
variable en un intervalo es igual a su valor en el estado inicial del
intervalo.
f(e
1
, . . . , e
k
) =
f(
e
1
, . . . ,
e
k
), de manera de que
la interpretacion del smbolo de funcion f se aplica a las interpretacio-
nes de e
1
, . . . , e
k
.
p(e
1
, . . . , e
k
) =
p(
e
1
, . . . ,
e
k
) . De forma similar
a la denici on anterior.
e
i
= e
j
= true
e
i
=
e
j
w = true
w = false
w
i
w
j
= true (
e
i
= true) (
e
j
= true)
e =
1
,...,
||
1
,...,
||
w =
true.
13
3.4 Interpretaci on. 3 L
w = true i [[ :
i
,...,
||
w = true.
A partir de aqu podemos derivar otros tantos operadores secundarios que
se apoyen en las deniciones anteriores pero que faciliten un poco la creaci on
de proposiciones m as ricas.
w = true i [[ :
i
,...,
||
w = true. Este es el
operador ((a veces)) (sometimes) y es el dual de always, ya que w
puede ser denido como w.
len(e) = true
ON L
OGICA.
4. Programaci on L ogica.
La sem antica de los programas logicos fue desarrollada por Van Emden y
Kowalski [83] y, seg un este ultimo, deben seguir una meta clara [44] respecto
a los problemas que se pretenten resolver: ((Los programas logicos deberan
especicar que va a ser computado; no como va a ser computado)). Es decir,
mientras que en la programaci on algortmica, la de lenguajes como C o Java,
el control de la ejecuci on va ligado a las instrucciones que resuelven el pro-
blema, en la programacion declarativa en la que se incluye la programaci on
l ogica s olo se deberan especicar el conocimiento y las asunciones que sobre
un problema especco se tiene. Lo que se consigue por medio de las llama-
das cl ausulas de Horn (clausulas con un literal positivo como m aximo). Estas
cl ausulas constituyen el sistema de axiomas que componen un programa l ogi-
co, de manera que la prueba de satisfactibilidad del conjunto de clausulas se
corresponda con la ejecuci on del programa.
Denotamos como clausula de Horn la expresi on A B
1
, . . . , B
n
y, en su
forma clausulada, (B
1
. . . B
n
) A = B
1
. . . B
n
A, donde solo
hay, como m aximo, un literal positivo A al que se denomina cabeza, mientras
que al resto de literales B
i
se les denomina cuerpo. De esta manera podemos
hacer una lectura aproximada diciendo que si cada B
i
es una formula cierta,
entonces A tambien lo es.
Las clausulas de Horn se clasican en dos tipos:
Clausula objetivo u objetivo, aquella que no tiene literales positivos,
B
1
. . . B
n
, donde cada B
i
es un sub-objetivo.
Clausula de programa, aquella que tiene al menos un literal negativo y
un unico literal positivo. Si la cl ausula de programa s olo consta de un
literal positivo A, se la llama clausula unitaria o hecho y se interpreta
que A es una formula cierta para cada asignacion de cada variable. Al
conjunto de hechos basicos se le suele denominar base de datos.
De esta manera podemos denir el programa l ogico como un conjunto de
predicados, donde cada uno es a su vez un conjunto de cl ausulas de Horn que
comparten el literal en sus cabezas.
16
4 PROGRAMACI
ON L
OGICA.
La importancia de las cl ausulas de Horn y el motivo por el cual son el me-
canismo sobre el que se construyeron lenguajes como Prolog, es la existencia
del metodo de resolucion lineal selectiva con cl ausulas denidas o SLD [43],
un metodo adecuado y completo cuando se aplica en sistemas de clausulas
de Horn. B asicamente el metodo consiste en aplicar derivaciones entre las
cl ausulas del programa P y la cl ausula objetivo G, de manera que una re-
futaci on de SLD sobre P G es una derivacion SLD nita de P G que
tiene la clausula vaca como ultimo objetivo en la derivaci on. El metodo se
desarrolla por recursi on mediante sustituci on por unicaci on. En realidad se
dene implcitamente un arbol de b usqueda de las computaciones alternati-
vas aplicando razonamiento con vuelta atras, de forma que la raz del arbol
se asocia con la cl ausula meta incial y en el que cada nodo hoja es un nodo
satisfactorio si su cl ausula objetivo asociada es la cl ausula vaca. Si la cl ausu-
la asociada a un nodo hoja no es vaca pero su literal asociado ya no puede
unicarse con ninguna cl ausula de entrada, entonces se dice que el nodo es
un fallo.
Si bien la programaci on logica se aplica en un creciente n umero de pro-
blemas pertenecientes a muy diversos dominios, tambien adolece de ciertas
limitaciones. Es el caso de los problemas que requieren una nocion de cambio
din amico en el tiempo. A veces se ha intentado extender la programaci on
l ogica con anotaciones, sistemas de predicados a nadidos y otros mecanismos,
y aunque estas son sin duda grandes contribuciones al mundo de la programa-
ci on, terminan por difuminar el caracter l ogico de los programas. La solucion
no pasa por a nadir caractersticas no l ogicas a la programaci on logica, sino
en desarrollar mejores y m as potentes herramientas como las logicas modales
o temporales.
En este sentido se presentan las l ogicas temporales, ya que representan
la mejor manera de extender la programacion l ogica para modelar propie-
dades din amicas dependientes del tiempo como las usadas en razonamiento
temporal o simulacion. Existen propuestas para extender la programacion
l ogica con l ogica temporal e incluso implementaciones operativas con algu-
nas restricciones con respecto al desarrollo te orico. Una buena parte de estas
implementaciones de lenguajes temporales han sido construidas sobre Prolog,
ya sea con modicationes en el algoritmo de unicaci on interno SLD o con
reglas extra para los operadores temporales.
17
4.1 Programaci on en l ogica temporal. 4 PROGRAMACI
ON L
OGICA.
4.1. Programaci on en logica temporal.
Las siguientes implementaciones estan basadas en los conceptos m as sim-
ples de la logica temporal b asica lineal y de ramicacion explicados en la
secci on 2.1, extendiendolos seg un las necesidades de cada lenguaje.
4.1.1. Chronolog.
Chronolog fue concebido por Wedge [86, 87] como propuesta sobre la
programaci on logica basada en cl ausulas de Horn antes de su materializaci on
denitiva como lenguaje [62, 63, 72]. Utiliza el conjunto de los naturales como
la colecci on de momentos en el tiempo y consta de dos operadores temporales:
rst, para referirse al momento inicial en el tiempo.
next, usado para el momento siguiente.
Esta concepci on implica una noci on de movimiento a traves del eje temporal.
4.1.2. Templog.
Originalmente propuesto por Abadi y Mann [1, 2], Templog utiliza un eje
temporal lineal y discreto con un futuro sin acotar basado en el conjunto de
los n umeros naturales. Templog tiene la misma sintaxis que Prolog excepto
por los tres operadores temporales que introduce:
, el siguiente momento en el tiempo.
, a partir de ahora.
, alguna vez en el futuro.
Surgen as algunos conceptos nuevos:
next-atom, atomos con un prejo de operadores next. Se denota por
k
A, donde A es un atomo y
k
es una k-aplicaci on del operador next,
esto es, aplicar k veces el operador next para valores de k 0.
next-formula, formula compuesta de next-atoms.
clausula inicial , cl ausula de la forma B A
1
, . . . , A
n
donde cada B y
cada A
i
son next-formulas.
18
4.1 Programaci on en l ogica temporal. 4 PROGRAMACI
ON L
OGICA.
clausula permanente, an alogamente, clausula de la forma B A
1
, . . . , A
n
donde cada B y cada A
i
son next-formulas. La diferencia con la clausula
inicial es el car acter temporal, ya que la clausula permanente implica
al operador .
Podemos denir ahora un programa en Templog como una conjunci on de
cl ausulas iniciales y permanentes, siendo el objetivo una conjunci on de next-
formulas. Su procedimiento de resolucion, llamado TSLD , tiene un n umero
de reglas para tratar con los operadores temporales. De hecho, el poder ex-
presivo de Templog es el mismo que el de un fragmento de s mismo llamado
TL1 en el que el unico operador temporal es .
Si bien puede demostrarse que tanto Chronolog como Templog tienen el
mismo poder expresivo simplemente sustituyendo el operador por next y
aplicando rst a todas las clausulas iniciales de Templog, el resultado no
tiene mayor trascendencia que el meramente te orico.
4.1.3. Temporal Prolog de Gabbay.
En [31] Gabbay propuso una extensi on de Prolog, a la que llam o conve-
nientemente Temporal Prolog, que haca posible el uso de conectivas tempo-
rales y modales en la programaci on l ogica. Estas conectivas fueron en prin-
cipio P, para expresar alguna vez en el pasado, F, para alguna vez en el
futuro, y para la nocion de siempre. Aunque el lenguaje es muy expresivo
e incluso permite implicaciones anidadas, no puede usarse en las cl ausulas
de programa. La sintaxis del lenguaje [32] es la que sigue:
programa, compuesto por un conjunto de clases.
clausula, que puede ser una clausula ordinaria o la cl ausula siempre.
clausula siempre, denida como A donde A es una cl ausula ordinaria.
clausula ordinaria, que puede tener solo una cabeza o una cl ausula del
tipo A H donde A es el cuerpo y H la cabeza.
cabeza, siendo esta una f ormula at omica o una construcci on de la forma
FA o PA, donde A es una conjunci on de clausulas ordinarias.
cuerpo, denido como una f ormula atomica, una conjunci on de cuerpos,
o una f ormula del tipo FA o PA donde A es un cuerpo.
19
4.2 Programaci on en l ogica de intervalos.4 PROGRAMACI
ON L
OGICA.
La admisi on de los operadores F y P en la cabeza de una cl ausula de progra-
ma provocan, de acuerdo a Orgun y Wadge [63], que esta extensi on de Prolog
no cumpla con la sem antica de modelo mnima. Aunque existen conjeturas
que apuntan en la direcci on contraria [64].
4.1.4. Temporal Prolog de Sakuragawa.
Otra implementacion llamada igualmente Temporal Prolog es la propues-
ta por Sakuragawa [74, 1, 2]. La particularidad de esta extensi on respecto a
las dem as es que Sakuragawa consider o en su lenguaje que todas las clausulas
de pograma son causales, esto es, el signicado de los predicados en el futuro
depende de su signicado en el pasado. Los operadores temporales relativos
a tiempos pasados como (momento previo en el tiempo) pueden darse en
la cabeza de una cl ausula, lo que provoca que programas escritos en esta
versi on de Temporal Prolog no sean traducibles directamente a otros como
el de Gabbay, Templog o Chronolog.
4.2. Programaci on en logica de intervalos.
Como se describe en la secci on 3, la l ogica temporal de intervalos es una
forma de logica temporal en la cual la semantica de las formulas se dene por
medio de interpretaciones temporales y pares, es decir, pares de momentos
en el tiempo que representan una duracion especca. Los dos lenguajes mas
representativos de este tipo de l ogica son Tempura [60, 35] y Tokio [4], ambos
considerados lenguajes para programaci on temporal en un sentido amplio.
Este tipo de lenguajes, aunque pueden usar los mecanismos en su ejecu-
ci on, no est a basado en el paradigma habitual de la programaci on l ogica de
resoluci on y unicaci on. Incluso incluyen algunas caractersticas heredadas
de los lenguajes funcionales.
4.2.1. Tempura.
El lenguaje Tempura, propuesto por Moszkowski [60], ha llevado un desa-
rrollo paralelo a la l ogica temporal de intervalos a la que se debe, aunque su
implementaci on mantiene una noci on discreta del tiempo. No es de extra nar,
por tanto, que todos los operadores y sintaxis de la ITL tengan cabida en
el lenguaje con una traduccion casi inmediata. Los operadores basicos de
20
4.2 Programaci on en l ogica de intervalos.4 PROGRAMACI
ON L
OGICA.
Tempura son (always) y (sometimes), implementa el operador secuen-
cial chop mediante la sintaxis ;, el operador (next) y las conjunciones
de formulas y expresiones a traves de and. A partir de estos elementos, un
programa Tempura es un conjunto de formulas ejecutables, aunque tambien
existe un conjunto de operadores secundarios, denidos sobre los anteriores,
para facilitar la tarea del programador y hacer el lenguaje m as asequible.
Otra decision de dise no importante es la de eliminar la disyunci on y la
negaci on en aras de la eciencia.
Las ejecuciones de los programas escritos para Tempura consisten en pro-
cesos de reduccion, debido a que en cada ejecuci on el programa se reduce
conforme a las operaciones en los intervalos de tiempo, y se repite el proceso
sucesivamente hasta que el subintervalo actual a evaluar s olo consta de un
estado, esto es, el intervalo no puede volver a ser dividido.
4.2.2. Tokio.
Tambien basado en la ITL e inuenciado por Tempura, se presenta el
lenguaje Tokio para descripci on de componentes hardware propuesto por
Aoyagi, Fujita, and Moto-oka [4].
Los operadores principales de Tokio son:
concurrency(, ), la clausula P :- Q, R signica que Q y R son ejecuta-
dos al principio de un intervalo de tiempo de manera concurrente.
chop(&&), operador que divide un intervalo de tiempo en dos subin-
tervalos. La cl ausula P :- Q && R signica que Q ser a ejecutado al
principio del primer subintervalo y R al principio del segundo.
next(@), la cl ausula P :- @Q signica que Q ser a ejecutado en el inter-
valo de tiempo inmediatamente posterior al actual.
always(#), la cl ausula P :- #Q signica que Q se ejecutara en todos
los subintervalos que componen el intervalo de P.
sometime <>, la clausula P :- <>Q signica que Q ser a ejecutado en
alg un momento en el intervalo en que P es ejecutado.
21
4.3 Programaci on en l ogica reicada. 4 PROGRAMACI
ON L
OGICA.
keep, la cl ausula P :- keep(Q) signica que Q ser a ejecutado en cada
subintervalo de P excepto en el nal.
final(fin), la cl ausula P :- fin(Q) signica que Q s olo ser a ejecutado
en el intervalo nal de P.
Los intervalos pueden ser manipulados usando determinados operadores de-
nidos en el lenguaje como length, empty y notEmpty. La ejecuci on de un
programa Tokio es una mezcla de resoluci on y reduccion. En lo relativo a la
unicaci on de variables, al igual que en Tempura, estas pueden variar con
el tiempo, por lo que el proceso de unicacion es complicado y se divide en
dos tipos: uno para unicar dos valores de variables Tokio, y el otro usando
directivas especiales para unicacion de variables en momentos especcos.
4.3. Programaci on en logica reicada.
Con la nalidad de completar un cat alogo b asico de opciones en progra-
maci on logica, incluimos tambien dos implementaciones no basadas en los
conceptos clasicos de la l ogica temporal, de intervalos o no.
4.3.1. Temporal Prolog de Hrycej.
Hrycej tambien desarroll o una extension a la que llam o Temporal Pro-
log [40], aunque en esta ocasi on no estaba basada directamente en logica
temporal, sino que implementa la sem antica de la l ogica temporal en Prolog,
siendo capaz de manejar sentencias l ogicas referenciadas temporalmente y
restricciones temporales.
Al igual que las anteriores Temporal Prolog, tambien est a construido sobre
Prolog introduciendo en este caso dos tipos adicionales de cl ausulas:
Referencias temporales, usadas para armar que se tiene una cierta
sentencia exactamente durante un intervalo de tiempo.
Restricciones temporales, que permiten crear axiomas para las relacio-
nes entre los intervalos de tiempo.
El propio Hrycej se nal o en [40] como aplicacion de su extensi on la planica-
ci on y consulta de bases de datos, as como la potencial aplicaci on en fsica
cualitava [41].
22
4.3 Programaci on en l ogica reicada. 4 PROGRAMACI
ON L
OGICA.
4.3.2. Starlog.
Starlog es un lenguaje de programacion temporal capaz de manejar al-
gunos problemas en los que el tiempo tiene una papel fundamental. Al igual
que el anterior, tampoco esta basado directamente en la logica temporal,
de hecho, siquiera proporciona operadores temporales, sino que simplemente
a nade un argumento adicional a cada predicado de Prolog [21].
23
5 REPRESENTACI
ON DEL CONOCIMIENTO.
5. Representaci on del conocimiento.
Sowa deende que, dado un dominio, la tarea de construir sobre el modelos
computables usando para ello la logica y las ontologas es lo que conocemos
como representacion del conocimiento [77]. Insiste en la importancia de es-
tablecer relaciones entre el conocimiento del mundo real y modelos capaces
de ser computados. Tanto es as que lleg o a proponer un tipo especial de
grafos, a los que llam o grafos conceptuales, como la representaci on universal
del conocimiento [78].
Valga esta mencion para ilustrar la importancia, la relevancia y la ade-
cuaci on de los grafos para la representacion del conocimiento, lo que es una
aproximaci on habitual en Inteligencia Articial [17]. En nuestro caso, sin em-
bargo, las bases de conocimiento que se suelen manejar en la programaci on
l ogica son, por as decirlo, mas planas. A modo de ejemplo, las bases de co-
nocimiento en Prolog no son m as que sucesiones de hechos que se dan por
v alidos escritos, en principio, sin ninguna relaci on sem antica entre ellos.
No obstante, cuando se trata de l ogicas temporales la situaci on vara un
poco, ya que es necesario expresar la nocion de temporalidad, algo que
com unmente se ha venido haciendo representando los estados
i
del inter-
alo como nodos de un grafo cuyas aristas denotan no solo el paso de un
estado a otro, sino el transcurso del tiempo. Veremos a continuacion dos de
las construcciones m as habituales para almacenar la din amicas temporales
sobre las que posteriormente podremos vericar proposiciones.
5.1. Sistemas de transici on etiquetados.
Un sistema de transicion etiquetado (LTS de sus siglas en ingles) es b asi-
camente un grafo dirigido con etiquetas en las aristas, donde los estados
equivalen a los vertices y las transiciones etiquetadas a las aristas con eti-
quetas. Se utilizan a menudo para denir el comportamiento de un proceso
que cambia en el tiempo. Los estados modelan los estados del sistema y las
transiciones etiquetadas modelan las acciones llevadas a cabo por el sistema.
24
5.2 Estructuras de Kripke. 5 REPRESENTACI
ON DEL CONOCIMIENTO.
Un sistema de transici on etiquetado sobre el conjunto de acciones / y el
de predicados {, es una tripleta 'S, , [=` donde [81]:
S es un conjunto no vaco y numerable de estados.
es una colecci on de relaciones binarias (transiciones)
a
SS una
para cada a /, tales que s S, t S[s
a
t es un conjunto.
[= S {, de forma que s [= p signidica que el predicado p P se da
en el estado s S.
Informalmente, una transicion se da cuando el sistema se encuentra en un
estado s
i
que puede efectuar la acci on a
l
y entonces va al estado s
j
. Lo
denotamos por s
i
a
l
s
j
, es decir, hay una transici on etiquetada por a desde
el estado s
i
al estado s
j
. Si, ademas, desde el estado s
j
existe una transicion
etiquetada con a
m
tal que s
j
am
s
k
, entonces se puede componer la notaci on
y escribir s
i
a
l
s
j
am
s
k
, o lo que es lo mismo, s
i
a
l
a
k
s
k
. En general, la
composici on de transiciones se puede expresar como s
1
a
1
a
2
...an
s
2
.
Conviene resaltar la importancia del no determinismo de los sistemas de
transici on etiquetados, ya que incluso tomando la misma secuencia de accio-
nes el sistema puede acabar en estados distintos.
5.2. Estructuras de Kripke.
Podemos decir que una estructura de Kripke es un sistema de transicion
etiquetado donde el conjunto de transiciones solo consta de una relacion
binaria simple sobre S. Este tipo de estructuras de Kripke son las usadas
en logica modal y, por tanto, en l ogica temporal. Aunque no son las unicas
que existen. Si por ejemplo permitimos que / sea un conjunto arbitrario de
acciones tendramos estructuras de Kripke para l ogica polimodal.
Formalmente, denimos una estructura de Kripke sobre los conjuntos /
y { de acciones y predicados respectivamente, como una 4-tupla M =
'S, I, T, l` donde:
S es el conjunto de estados.
I S denota el conjunto de estados iniciales.
25
5.2 Estructuras de Kripke. 5 REPRESENTACI
ON DEL CONOCIMIENTO.
T S S es una relaci on de transici on entre estados.
l : S {(/) es la funcion de etiquetado de estados que asigna a cada
estado un proposici on de /.
Las estructuras de Kripke pueden usarse para modelar la sem antica de la
l ogica, usando por ejemplo los habituales operadores X (next time), F (even-
tuality), G (globally), U (until ), y R (release) [12]. Para ello podemos re-
presentar cada estado como un vector s = 's(1), . . . , s(n)`, donde cada s(i)
con i = 1, . . . , n es una variable proposicional, y establecer que cada estado
tenga un estado sucesor, es decir s S, t S de manera que 's, t` T,
lo que tambien podemos escribir como s t. Dada una secuencia innita
de estados = 's
1
, s
2
, . . .`, denimos (i) = s
i
y = (s
i
, s
i+1
, . . .)i N.
Una secuencia innita de estados es un camino si (i) (i + 1) i N.
Decimos que la f ormula f es v alida a lo largo de , denotado como [= f, si
para el camino en la estructura de Kripke M podemos decir:
[= p si y s olo si p l((0))
[= p si y s olo si p / l((0))
[= f g si y s olo si [= f y [= g
[= f g si y s olo si [= f o [= g
[= Gf si y s olo si i,
i
[= f
[= Ff si y s olo si i,
i
[= f
[= Xf si y s olo si
1
[= f
[= fUg si y s olo si i[
i
[= g y j < i,
j
[= f]
[= fRg si y s olo si i[
i
[= g o j < i,
j
[= f]
De esta manera, una formula f es universalmente valida en una estructura
de Kripke M, y denotamos M [= Af, si y s olo si [= f M, (0) I.
Por otra parte, es existencialmente valida, M [= Ef, si y s olo si [= f
M, (0) I
26
5.3 Consideraciones. 5 REPRESENTACI
ON DEL CONOCIMIENTO.
5.3. Consideraciones.
Aunque como hemos visto las estructuras de Kripke son una forma de
sistema de transici on etiquetado, De Nicola y Vaandrager [25] desarrollaron la
l ogica ACTL* para sistemas de transci on etiquetados, probando ser igual de
potente que CTL* [28], una logica interpretada sobre estructuras de Kripke.
En su trabajo establecen dos metodos para mapear estructuras de Kripke a
sistemas de transici on etiquetados y viceversa, as como sendas funciones de
transformaci on entre las dos logicas preservando los valores de verdad.
Por tanto, resulta indiferente cual de las dos construcciones escojamos
para la representaci on del conocimiento, puesto que son, de hecho, estruc-
turas equivalentes con el mismo poder expresivo. Siendo ademas ambas ca-
sos especcos de grafos etiquetados, las dos pueden ser representadas sobre
cualquiera de las bases de datos en grafo existentes. Para nuestro proposi-
to tomaremos las estructuras de Kripke como la manera de representar el
conocimiento.
27
6 BASES DE DATOS EN GRAFO.
6. Bases de Datos en Grafo.
Como se nalan Orgun & Ma [64], la potencia de las logicas temporales
ya ha sido satisfactoriamente probada en la resoluci on de problemas como
la especicacion y vericacion de programas [46, 54], el razonamiento tem-
poral [18, 73], la inteligencia articial [76, 6] o las bases de datos tempo-
rales [22, 82, 33]. Sin embargo, aunque en este ultimo campo se han hecho
grandes avances, la mayora de las aproximaciones a sistemas de consulta han
seguido las directrices del algebra relacional, el lenguaje SQL, la ling ustica
computacional o incluso el c alculo de dominios por ejemplos [65]. Es decir,
ninguna de las propuestas ha abandonado el paradigma de las habituales
bases de datos relacionales, transacionales o no. Ocasion de mas para pre-
guntarse que pueden ofrecernos a este respecto las nuevas bases de datos no
relacionales [79] y, en concreto, las bases de datos basadas en grafo, cuyos
lenguajes de consulta est an fuertemente inspirados en repositorios de datos
libres de esquema y algoritmos sobre grafos.
Dentro del grupo de las recien nombradas bases de datos NoSQL [80]
(acr onimo que se acerca mas a una invitacion a completar el ya anciano len-
guaje de consultas que a un posicionamiento en su contra ((Not only SQL))
en lugar de ((No to SQL)) [27]), podemos encontrar una nueva generacion de
motores de bases de datos dise nados y construidos con herramientas actuales
y manteniendo en mente desde un principio la escalabilidad, la latencia de
respuesta, la abilidad y la replicaci on como los puntos centrales. En este
sentido va la queja de Michaek Stonebraker et al. cuando concluye que ((las
lneas de codigo de los actuales sistemas gestores de bases de datos, mientras
intentan ser una soluci on ((que se ajuste a todo)), de hecho, no se ajustan a
nada)), en el sentido de que no pueden competir con las soluciones especcas
que existen en el mercado. Esto, unido al incipiente desarrollo de un siste-
ma para procesado online de transacciones (OLTP) denomiando H-Store,
supuso un punto de inexi on en el actual panorama de las bases de datos,
produciendose el salto denitivo hacia la nueva generaci on.
Es en este nuevo paradigma en el que se sit uan las bases de datos que basan
su estructura y funcionamiento en la teora de grafos. Sin embargo no son
28
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
las mas populares, puesto que por las necesidades de los sistemas actuales
se suelen demandar otro tipo de caractersticas, como las almacenes o caches
clave-valor, los servidores de estructuras, las bases de datos documentales
u orientadas a objetos, y los almacenes de tuplas y por columnas [80]. No
obstante, el desarrollo te orico de los modelos para bases de datos basadas
en grafo es muy anterior. Podemos decir que un modelo de base de datos en
grafo es aquel en el que o bien las estructuras de datos, o bien los propios
datos en s (instancias de la base de datos), o ambos, son modelados como
grafos (dirigidos y/o etiquetados) o como estructuras de datos con la nocion
de grafo (hipergrafos o hipernodos) [3]. Ademas los datos se manipulan a
traves de una serie de primitivas de transformaci on sobre el grafo.
El tercer punto clave en los modelos de bases de datos en grafo es la inte-
gridad de la informaci on, ya que suelen existir mecanismos que garanticen de
alguna manera la consistencia de los datos respecto del esquema, mantengan
la integridad referencial y de los identicadores, y satisfagan las dependencias
funcionales y de inclusi on [34, 47, 50, 42]. Pero no siempre son necesarios.
Las nuevas bases de datos basadas en grafo suelen ser denominadas, de he-
cho, libres de esquema, ya que cualquier restriccion que coarte la libertad a
la hora de introducir los datos y las relaciones entre ellos debera colocarse
en una capa superior a la de la persistencia, ya que no implementan (o no
suelen implementar) tales restricciones.
En estos entornos, reejar cualquiera de las estructuras denidas en las
secciones 5.1 y 5.2 resulta trivial, puesto que como se nalamos anteriormente
ambas construicciones son casos particulares de grafos etiquetados.
6.1. Bases de datos.
Aunque puede parecer un campo de reciente creacion, las bases de da-
tos en grafo cuentan con una buena lista de opciones que han demostrado
ser satisfactorias desde el punto de vista de las necesidades del mercado. A
continuacion describimos algunas de las mas populares.
29
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
6.1.1. DEX.
DEX
3
[55] es, seg un sus creadores, una ((biblioteca de alto rendimeinto
para gestionar grandes grafos o redes)), en concreto, soporta multigrafos diri-
gidos y etiquetados con atributos. De origen academico, desde marzo de 2010
DEX es mantenida y comercializada por la compa na Sparsity-Technologies
4
,
una entidad saliente de la Universidad Politecnica de Catalu na.
Desarrollada por y para Java, tiene bindings para la plataforma .NET R (,
de Microsfot R (, y es capaz de funcionar en plataformas Windows R (y Linux.
Su licencia es unicamente propietaria, aunque la descarga gratuita por mo-
tivos de investigaci on y evaluaci on s esta permitida. Completamente libre
de esquema, permite la ejecuci on de traversals como metodo de consulta,
aunque no proporciona un lenguaje especco para ello.
6.1.2. FlockDB.
Inicialmente desarrollada para la red social twitter
5
[67], FlockDB
6
es
una base de datos en grafo para la gesti on de datos a escala Web. El sistema
est a construido para ser totalmente distribuido, tolerante a fallos y bajo la
propuesta teorica MapReduce [24].
Liberada como sofware libre bajo una licencia de tipo Apache
7
, los desa-
rrolladores del proyecto deenden que es mucho m as simple que el resto de
bases de datos en grafo existentes, tanto es as que hasta mediados de 2011
no contaba aun con un lenguaje de consulta para grafos.
6.1.3. HyperGraphDB.
HyperGraphDB
8
es un framework de almacenamiento basado en hiper-
grafos generalizados como modelo de datos subyacente. Se podra pensar en
su modelo de datos como un modelo relacional en el que se permiten rela-
ciones n-arias de un orden superior; o como un modelo orientado a grafos
3
DEX: http://sparsity-technologies.com/dex
4
Sparsity-Technologies: http://www.sparsity-technologies.com
5
Twitter: http://twitter.com
6
FlockDB: https://github.com/twitter/flockdb
7
Apache Licenses: http://www.apache.org/licenses/
8
HyperGraphDB: http://www.hypergraphdb.org/index
30
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
donde las aristas pueden apuntar a un conjunto arbitrario de nodos y de
otras aristas. La unidad de almacenamiento es una tupla compuesta de 0 o
m as tuplas donde cada una es llamada un atomo. Cada atomo tiene un va-
lor arbitrario y fuertemente tipado asociado. El sistema de gesti on de tipos
de esos valores est a embebido como un hipergrafo y se puede modicar en
cualquier momento.
HyperGraphDB es en s misma una base de datos embebida con un fra-
mework de distribucion basado en el protoclo XMPP
9
, que ademas funciona
internamente con un almacen clave-valor: una base de datos BerkeleyDB [61].
En su forma actual esta concebida como base de datos orientada a objetos
para Java. El almacenamiento, el indexado y el cacheo han sido dise nados
para permitir consultas sobre el grafo bien por recorridos (traversals) o por
coincidencia de patrones (pattern matching).
Disponible para las plataformas Windows, MacOS y Linux, est a licenciado
bajo los terminos de la Lesser GPL
10
.
6.1.4. InfoGrid.
Pensada para la Web, InfoGrid
11
cuenta con varios componentes adicio-
nales que pretenden facilitar el desarrollo de aplicaciones web RESTful [69]
sobre grafos. Algunos de estos componentes son:
Graph Database Project. Desarrolla el n ucleo de InfoGrid. Puede usarse
de manera autonoma como base de datos en grafo o en conjunci on con
otros proyectos.
Grid Project. Aumenta la capacidad de la base de datos en grafo con
un protocolo para replicacion, de manera que diferentes bases de datos
puedan colaborar gestionando grafos realmente grandes.
Stores Project. Proporciona una interfaz com un para distintas tecno-
logas de almacenamiento tales como bases de datos SQL y tablas hash
9
XMPP Standars Foundation: http://xmpp.org/
10
GNU Lesser General Public License: http://www.opensource.org/licenses/
lgpl-3.0.html
11
InfoGrid: http://infogrid.org/
31
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
NoSQL distribuidas. Permite, por tanto, dotar de varios sistemas dife-
rentes de almacenamiento pero con la misma API para los desarrolla-
dores.
Model Library Project. Dene una biblioteca de modelos de objetos
reusable que pueden ser utilizados como esquemas en las aplicaciones.
Con una licencia Aero GPL
12
, InfoGrid ofrece opciones de soporte comer-
cial a traves de la compa na NetMesh
13
.
6.1.5. InniteGraph.
InniteGraph
14
es una base de datos en grafo distribuida dise nada para
soportar aplicaciones que generan modelos de datos en grafo, complejos y
con un gran volumen. Proporciona la capacidad de reducir la escala de los
modelos de datos y grafos en m ultiples bases de datos y m ultiples grafos.
Soporta una variedad de implementaciones de sistema y despliegues, co-
mo pueden ser sistemas basados en servidores, plataformas en la nube o
aplicaciones embebidas. Ofrece una API dedicada para uso directo con el
modelo de datos en grafo junto con una capa de persistencia distribuida y
altamente escalable. Mientras que su arquitectura est a dise nada para sopor-
tar requisitos de alto rendimiento y escalabilidad, la API es muy simple y
en principio solo requiere de un mnimo esfuerzo de desarrollo y dise no para
que los programadores puedan construir r apidamente los sistemas seg un sus
necesidades.
La compa na que se encarga de la licencia de la base de datos es Objectivity,
Inc.
15
, de la que forma parte InniteGraph desde el a no 2010.
12
GNU Aero General Public License: http://www.gnu.org/licenses/agpl-3.0.
html
13
NetMesh: http://netmesh.us/
14
InniteGraph: http://www.infinitegraph.com/
15
Objectivity, Inc.: http://www.objectivity.com/
32
6.1 Bases de datos. 6 BASES DE DATOS EN GRAFO.
6.1.6. Neo4j.
La base de datos Neo4j
16
es quiz as una de las m as conocidas y activamente
desarrolladas, en la que la fuerte implicaci on de la comunidad proporciona el
empuje necesario para que avance en las direcciones que los desarrolladores
demandan.
Neo4j es una base de datos en grafo NoSQL de alto rendimiento, con to-
das las caractersticas de una base de datos robusta y madura. De cara al
programador, ofrece una buena orientaci on a objetos y una estructura de red
exbile, en lugar de estrictas tablas estaticas. Sin embargo, sigue proporcio-
nando todos los benecios de las bases de datos empresariales y completa-
mente transacionales. Se nalan en su web que incluso hay estimaciones sobre
otras bases de datos relacionales que arrojan mejoras del orden del 1000 %
en velocidad, aunque tales referencias no han podido ser contrastadas.
Es un proyecto de codigo abierto disponible bajo una licencia GPL v3 para
su edici on Community, y con ediciones Advance y Enterprise disponibles
como Aero GPL y con soporte por la compa na Neo Technology
17
bajo una
licencia comercial.
6.1.7. OrientDB.
OrientDB
18
es un sistema gestor de bases de datos documentales y en
grafo escalable y que presume de ser tan exible como las bases de datos
documentales y tan poderosa para gestionar enlaces como las bases de datos
en grafo. Puede trabajar en modo libre de esquema, con soporte completo
de esquema o en un modo mixto. Soporta caractersticas como transacciones
ACID [38], ndices r apidos, y consultas nativas y SQL. Importa y exporta
documentos en formato JSON
19
.
El algoritmo de indexado es de invenvion propia. Recibe el nombre de
MVRB-Tree y es una derivaci on del Red-Black Tree [75] y los B+Tree [9] pero
con las ventajas de ambos: insercion rapida y b usquedas aun mas r apidas.
16
Neo4j: http://neo4j.org/
17
Neo Technology: http://neotechnology.com/
18
OrientDB: http://www.orientechnologies.com/
19
JSON, JavaScript Object Notation: http://json.org/
33
6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.
El motor transacional puede ser ejecutado en sistemas distribuidos y soporta
varios billones de registros con una capacidad m axima de billones de terabytes
de datos distribuidos en m ultiples discos en m ultiples nodos.
OrientDB es de libre uso y est a distribuida bajo los terminos de una licencia
Apache 2.0
20
.
6.2. Lenguajes de consulta.
Por desgracia, en el terreno de las bases de datos en grafo no existe, al con-
trario que en las relacionales, un lenguaje de consulta com un estandarizado
y completo que cumpla con los requisitos de las distintas implementaciones.
Si bien se han hecho intentos, estos han resultado ser por un lado incom-
pletos y por otro demasiado especcos a una tecnologa o disposicion de los
datos concretos. Es por ello que no podemos s olo describir uno solo sino va-
rios de los lenguajes de consulta desarrollados para atacar bases de datos e
informaci on dispuesta a modo de grafo.
6.2.1. GQL.
GQL [66] es un lenguaje de consultas gr aco basado en el modelo de datos
funcional y que puede expresar todas las consultas del algebra relacional.
6.2.2. GraphLog.
Bas andose en la representacion en grafo tanto de datos y como de consul-
tas, Consens y Mendelzon denieron el lenguaje de consultas llamado Graph-
Log [23]. En GraphLog, las consultas son patrones de grafos y las aristas en
las consultas representan caminos en la base de datos.
A da de hoy no parece existir una implementaci on de referencia funcio-
nal y correcta. El sistema gestor de bases de datos Oracle a nadio soporte
para GraphLog [49], pero se desonoce si los fundamentos que usaron son los
mismos que los expuestos a nivel te orico.
20
Apache License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0.html
34
6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.
6.2.3. Gremlin.
Basado en el algebra de caminos denida en [70], Gremlin es un lenguaje
para atravesar grafos (traversal ). Permite consultar un grafo y puede ex-
presar traversals complejos con poco esfuerzo, por lo que resulta util para
explorar y aprender sobre grafos. Mas extensivamente, la idea de aplicar el
algebra de caminos a las redes multi-relacionales ya ha sido explorada con
exito en [15, 53].
Desde el punto de vista tecnico existen varias implementaciones, aunque
se trata de un lenguaje que puede ser usado sobre distinas bases de datos.
Lo que permite independizar las consultas del backend de datos especco.
Por otra parte Gremlin es Turing-completo y proporciona numerosas cons-
trucciones en memoria y computadas para soportar reconimiento de patrones
arbitraros.
6.2.4. PQL.
Como se describe en [23, 57], el origen de PQL est a en el proyecto de
integraci on de datos geneticos GeneSeek. PQL incorpora muchas de las ca-
racterstica de los lenguajes de consultas para datos semi-estructurados y
generaliza el lenguaje StruQL, un lenguaje de consulta tambien para datos
semi-estructurados como el XML que permite construir caminos arbitrarios
sobre las relaciones en un documento sencillo.
A esto se le a nade la habilidad de expresar restricciones sobre los metadatos
como una mejora sobre la curacion de base de datos. Estas restricciones guan
la generacion dinamica de planes de consulta potenciales, lo que permite que
una consulta simple permanezca siendo practicamente la misma incluso en
presencia de esquemas que est an continuamente evolucionando, como es a
menudo el caso de la integraci on de datos.
6.2.5. SPARQL.
El World Wide Web Consortium (W3C) cre o en 2004 el protocolo SPARQL
y el lenguaje de consultas RDF [68]. RDF es un formato de datos en grafo
etiquetado y dirigido para la representacion de la informacion en la Web. Se
35
6.2 Lenguajes de consulta. 6 BASES DE DATOS EN GRAFO.
suele utilizar para representar, entre otras cosas, informacion personal, redes
sociales, metadatos sobre artefactos digitales, as como para proporcionar un
medio de integracion sobre orgenes dispares de informaci on. SPARQL, es el
lenguaje de consulta para RDF, est a dise nado para reunir los casos de uso
y requisitos identicados por el grupo de trabajo de RDF Data Access. El
lenguaje est a relacionado ntimamente a las siguientes especicaciones:
La especicaci on del Protocolo SPARQL para RDF (SPORT) que de-
ne el protocolo remoto para efectuar consultas SPARQL y recibir los
resultados.
La especicacion SPARQL Query Results XML Format (RESULTS)
que dene el formato de un documento XML para representar los re-
sultados de las consultas SPARQL SELECT y ASK.
6.2.6. UnQL/UnCAL.
UnQL es una propuesta de lenguaje de consulta sobre datos semi-estructurados
y XML [13] con una sintaxis similar a SQL. Funciona sobre las bases de la
recursi on estructural y el pattern matching de forma muy parecida a como
lo hace XLS sobre cheros XML pero deniniendo mecanismos para evitar
entrar en bucles innitos durante la evaluaci on. El algebra interna de UnQL
se denomina UnCAL y dene el concepto de recursion estructural sobre gra-
fos para, posteriormente, poder efectuar consultas sobre el conjunto de datos
aplicando la noci on de que una consulta UnCAL es en realidad una bisimu-
laci on generica.
Las consultas UnCAL son computables en NLOGSPACE, esto es, PTIME,
pero lamentablemente la unica implementaci on real de UnQL, pese a las
indicaciones acerca de las dos formas posibles de evaluar una consulta UnQL,
es la desarrollada por los propios autores para el Standard ML [5]. Por lo que
conviene no confundirlo con el sistema de identico nombre
21
desarrollado por
la compa na de reciente aparci on Couchbase
22
para consultar bases de datos
semi-estructuradas, cheros en formato JSON y bases de datos documentales.
Nada, por el momento, para bases de datos en grafo.
21
UnQL: http://www.unqlspec.org/display/UnQL/Home
22
Couchbase Server 2.0: http://www.couchbase.org/get/couchbase/2.0.0
36
7 L
V =
0
V , donde V es una propiedad. Es decir, el valor de una
propiedad en un grafo es igual a su valor en el nodo marcado como
inicial, siempre que no este contenida en una proposici on o formula que
implique operadores temporales.
w = false.
e =
1
,...,
||
len(e) = true