ES2553971T3 - Método y dispositivo para la evolución ontológica - Google Patents
Método y dispositivo para la evolución ontológica Download PDFInfo
- Publication number
- ES2553971T3 ES2553971T3 ES10717615.8T ES10717615T ES2553971T3 ES 2553971 T3 ES2553971 T3 ES 2553971T3 ES 10717615 T ES10717615 T ES 10717615T ES 2553971 T3 ES2553971 T3 ES 2553971T3
- Authority
- ES
- Spain
- Prior art keywords
- change
- ontology
- conceptual
- operators
- person
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
- G06F16/367—Ontology
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
- G16B50/00—ICT programming tools or database systems specially adapted for bioinformatics
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16B—BIOINFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR GENETIC OR PROTEIN-RELATED DATA PROCESSING IN COMPUTATIONAL MOLECULAR BIOLOGY
- G16B50/00—ICT programming tools or database systems specially adapted for bioinformatics
- G16B50/10—Ontologies; Annotations
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Life Sciences & Earth Sciences (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Medical Informatics (AREA)
- Spectroscopy & Molecular Physics (AREA)
- Bioethics (AREA)
- Biophysics (AREA)
- Evolutionary Biology (AREA)
- Biotechnology (AREA)
- Bioinformatics & Computational Biology (AREA)
- Mathematical Physics (AREA)
- Artificial Intelligence (AREA)
- Evolutionary Computation (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Animal Behavior & Ethology (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Machine Translation (AREA)
Abstract
Un método implementado por ordenador para modificar un mapeo desde al menos una ruta de aplicación de un sistema de datos usado por una aplicación informática a una ruta conceptual de un sistema de ontología enlazado con dicho sistema de datos, direccionando dicha ruta de aplicación 5 una parte de la estructura de dicho sistema de datos y direccionando dicha ruta conceptual una parte de la estructura del sistema de ontología, comprendiendo dicho método las etapas de - detectar un cambio en una parte de la estructura de dicho sistema de ontología que está direccionando una o más de dichas rutas conceptuales, siendo dicho cambio un cambio a nivel de base de lexon o a nivel de base de patrón, siendo dicha base de lexon un conjunto de lexones, definiendo cada lexon una relación entre dos términos en un contexto determinado, siendo dicha base de patrón un conjunto de patrones semánticos definidos por una selección de rutas conceptuales en dicha base de lexon y un conjunto de restricciones semánticas en dichas rutas conceptuales seleccionadas, describiéndose dicho cambio mediante una secuencia ordenada de primeros operadores que definen la información semántica sobre dicho cambio, - definir uno o más segundos operadores que operan en dicho mapeo, siendo dicho uno o más segundos operadores equivalentes a dicho uno o más primeros operadores usados para describir dicho cambio en dicha parte de la estructura de dicho sistema de ontología, - actualizar dicho mapeo con dicho uno o más segundos operadores equivalentes para reflejar el cambio en dicha parte de la estructura del sistema de ontología.
Description
5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Metodo y dispositivo para la evolucion ontologica Campo de la invencion
La presente invencion se refiere, en general, a la ingeniena de ontologfa. Mas espedficamente, la presente invencion se refiere a la evolucion de ontologfa y al mantenimiento de los cambios dentro de los sistemas de ontolog^a.
Antecedentes de la invencion
Internet y otros entornos de conectividad abierta crean una fuerte demanda por compartir la semantica de datos. Los sistemas de ontolog^a se estan convirtiendo cada vez mas en esenciales para casi todas las aplicaciones informaticas. Las organizaciones estan mirando hacia ellos como unos recursos semanticos procesables por maquina vitales para muchas areas de aplicacion. Una ontolog^a es un entendimiento acordado (es decir, la semantica) de un determinado dominio, axiomatizado y representado formalmente como la teona logica en la forma de un recurso basado en ordenador. Compartiendo una ontologfa, las aplicaciones autonomas y distribuidas pueden comunicarse de manera significativa para intercambiar datos y hacer de este modo transacciones interoperativas independientemente de sus tecnologfas internas.
Las ontologfas capturan el dominio del conocimiento de una parte espedfica del mundo real, por ejemplo, el conocimiento sobre la entrega del producto. Las ontologfas pueden verse como una representacion formal del conocimiento por un conjunto de conceptos y las relaciones entre estos conceptos dentro de un dominio. Las ontologfas deben capturar este conocimiento independientemente de los requisitos de aplicacion (por ejemplo, la aplicacion de entrega de producto de cliente frente a la aplicacion de entrega de producto de repartidor). La independencia de aplicacion es la disparidad principal entre una ontologfa y un esquema de datos clasico (por ejemplo, EER, ORM, UML) aunque cada uno captura conocimientos a nivel conceptual. Por ejemplo, muchos investigadores han confundido las ontologfas con esquemas de datos, bases de conocimiento, o incluso programas logicos. A diferencia de un esquema de datos conceptual o una base de conocimientos “clasica” que captura la semantica para una aplicacion de empresa determinada, la ventaja principal y fundamental de una ontologfa es que captura el conocimiento del dominio de manera muy independiente de cualquier aplicacion o tarea espedfica. Un consenso sobre el contenido ontologico es el principal requisito en la ingeniena de ontologfa, y esto es lo que la distingue principalmente del modelado de datos conceptual.
El area de investigacion de la ingeniena de ontologfa parece haber alcanzado un cierto nivel de madurez, teniendo en cuenta la gran cantidad de metodos y herramientas contemporaneos para la formalizacion y la aplicacion de modelos de representacion del conocimiento. Sin embargo, todavfa hay poca comprension de y apoyo para los aspectos evolutivos de las ontologfas. Esto es espedficamente importante en los entornos distribuidos y colaborativos en los que las ontologfas co-evolucionan de manera natural con sus comunidades de uso. Para gestionar la evolucion de las ontologfas individuales, se han adoptado con exito unas tecnicas establecidas a partir de la evolucion del esquema de datos, y parece emerger un consenso sobre un modelo de proceso de evolucion de ontologfa general.
Sin embargo, mucho menos explorado, es el problema de la evolucion de las ontologfas interorganizacionales. En este entorno dinamico y “complejo”, un modelo de proceso de cambio colaborativo requiere unas metodologfas mas poderosas de ingeniena, argumentacion y negociacion, complementadas por el apoyo de la gestion de dependencia de contexto. Resulta que se puede aprender mucho de otros dominios en los que se estan disenando objetos formales de manera colaborativa. En particular, el campo de la ingeniena de sistemas ofrece una gran cantidad de tecnicas y herramientas para versionar, mezclar y evolucionar los objetos de software, y muchas de estas tecnicas pueden reutilizarse en un entorno de ingeniena de ontologfa. El desaffo pendiente clave es construir un marco unico, basado en estos mecanismos, que pueda adaptarse a las necesidades de un entorno de version espedfico.
Las ontologfas a menudo reutilizan y amplfan (partes de) otras ontologfas. Existen muchos tipos diferentes de dependencias dentro y entre los objetos ontologicos de diversos niveles de granularidad, que van desde los conceptos individuales de las definiciones a ontologfas completas. Otros objetos dependientes incluyen casos, asf como los programas de aplicacion que comprometen a la ontologfa. Por lo tanto, un cambio en la solicitud en un objeto podna implicar una cascada de cambios en respuesta a todos sus objetos dependientes. Se necesita un metodo viable para registrar todas las implicaciones de la ontologfa y sus objetos dependientes.
El documento EP1970844 describe un metodo para el metamodelado que usa unos objetos de ontologfa dinamica. Los llamados “objetos ontologicos”, es decir, los conjuntos de interfaces e implementaciones de software, se actualizan sobre la base de los cambios en un metamodelo: cuando se ha realizado un cambio en el metamodelo, los objetos ontologicos se actualizan generando un nuevo codigo fuente. Un problema en este caso es que el cambio se realiza en el nivel de los objetos ontologicos. No existe un mapeado entre el modelo de ontologfa y el metamodelo. Sigue siendo diffcil para una aplicacion participante detectar y aplicar los cambios correspondientes a
5
10
15
20
25
30
35
40
45
50
55
60
65
la interfaz entre la aplicacion y los objetos ontologicos.
El mismo problema se produce en el documento US2007/162409, en el que se recibe una orden de un solicitante para modificar una tabla que incluye los conceptos de dominio y los primitivos semanticos relacionados con un dominio. La tabla se actualiza en respuesta a la orden. A continuacion, la tabla actualizada se almacena como una ontologfa.
En el documento “Dogma-Mess: A Meaning Evolution Support System for Interorganizational Ontology Engineering” (A. De Moor et al., Conceptual Structures: Inspiration and Application Lecture Notes in Computer Science, vol. 4068, 1 de enero 2006, paginas 189-202) se introduce un modelo para la ingeniena de ontologfa interorganizacional. El documento se limita a describir la evolucion de un sistema de ontologfa basado en un conjunto de especializaciones en esta ontologfa, estas ultimas llamadas ontologfas organizacionales. No describe los operadores de evolucion con gran detalle. Mas importante aun, no tiene en cuenta las aplicaciones mapeadas en el sistema de ontologfa. En otras palabras, no describe como evolucionan los mapeos entre rutas de aplicacion en un sistema de datos arbitrario y las rutas conceptuales en un sistema de ontologfa basado en los cambios aplicados al sistema de ontologfa. El documento menciona las operaciones de versionado y de cambio, pero no describe esto de una manera formal y detallada.
El documento “Data Modelling versus Ontology engineering” (P. Spyns et al., ACM Sigmod Record, vol. 31, N° 4, paginas 12-17, 31 de diciembre de 2002) describe la diferencia entre un modelo de datos y una ontologfa como se percibe por los autores, e introduce el enfoque de ontologfa DOGMA. No describe la evolucion de las ontologfas, ni describe como evolucionan los mapeos entre las rutas de aplicacion en un sistema de datos arbitrario para las rutas conceptuales en un sistema de ontologfa basado en los cambios aplicados a ese sistema de ontologfa.
El documento “Object Role Modelling for Ontology Engineering in the DOGMA Framework” (P.Spyns et al., On the Move to Meaningful Internet Systems 2005, OTM Workshop Lecture Notes, vol. 3762, paginas 710 a 719, 1 de enero 2005) se limita a una descripcion de algunas cuestiones basicas a tener en cuenta cuando se usa la metodologfa ORM para la ingeniena de ontologfa desde el punto de vista del marco de la ontologfa DOGMA. En primer lugar se trata la diferencia entre un modelo de datos y una ontologfa. Ademas se tratan las semanticas natural y formal. Por ultimo, el documento trata algunas etapas basicas a tener en cuenta en la construccion de las ontologfas. El documento no hace referencia a los temas de la evolucion o el versionado.
En el documento US2008/071731 se presenta una solucion para refinar de manera automatica la ontologfa dentro de un contexto espedfico. En el metodo propuesto se usa un denominado extractor de contexto rico para descubrir un conflicto de relacion semantica entre un esquema de ontologfa dado y unos datos de aplicacion. Este extractor descubre que ciertos datos de aplicacion contienen un contexto mas rico que el esquema de ontologfa existente al que estan mapeados. A continuacion, el sistema de ontologfa se refina con el contexto mas rico de los datos de aplicacion y se define una nueva grafica de mapeo entre la ontologfa refinada y los esquemas de datos originales.
Existe una necesidad de mantener y aplicar cambios a un sistema de ontologfa en el nivel de la interfaz entre el sistema de aplicacion y de ontologfa. Esto es especialmente necesario cuando se enlazan multiples aplicaciones al mismo sistema de ontologfa. La adaptacion de los cambios puede ser, de otro modo, un trabajo muy elaborado.
Objetivos de la invencion
La presente invencion tiene como objetivo proporcionar un metodo y un sistema para la evolucion de ontologfa flexible, con los que se puedan realizar un seguimiento de los cambios dentro del sistema de ontologfa.
Sumario de la invencion
La presente invencion propone actualizar los mapeos de las rutas de aplicacion en un sistema de datos a las rutas conceptuales en un sistema de ontologfa basado en los cambios detectados en ese sistema de ontologfa. Hay que tener en cuenta que, a diferencia de los objetos de ontologfa en las soluciones de la tecnica anterior (por ejemplo, el documento EP1970844), el sistema de datos en esta invencion no tiene que cambiarse durante el proceso, se cambian solo los mapeos. Un sistema de ontologfa se considera que esta enlazado con un sistema de datos usado por una aplicacion informatica. La ontologfa tiene una cierta estructura sintactica, en la que se definen unas rutas conceptuales. El sistema de datos tiene una estructura direccionable por las rutas de aplicacion. Se considera una situacion en la que se ha hecho un cambio en el sistema de ontologfa.
Mas espedficamente, la presente invencion proporciona un metodo para modificar un mapeo desde al menos una ruta de aplicacion de un sistema de datos a una ruta conceptual de un sistema de ontologfa, direccionando dicha ruta de aplicacion una parte de la estructura del sistema de datos y direccionando dicha ruta conceptual una parte de la estructura del sistema de ontologfa. El metodo comprende las etapas de:
- detectar un cambio en una parte de la estructura del sistema de ontologfa en el que se direcciona una o mas de las rutas conceptuales;
5
10
15
20
25
30
35
40
45
50
55
60
65
- actualizar los mapeos para reflejar el cambio en esa parte de la estructura del sistema de ontolog^a.
Algunos ejemplos de los cambios que se producen a menudo en una ontologfa (como, por ejemplo, reetiquetar, anadir, insertar, borrar) se proporcionan a continuacion.
En una realizacion preferida, el cambio detectado se almacena en un registro de cambios. Un registro de cambios de este tipo realiza un seguimiento de los diversos cambios en el sistema de ontologfa al pasar de una version a una version sucesora.
En una realizacion, el metodo comprende una etapa inicial de aplicacion de dicho cambio al sistema de ontologfa. Esta es una situacion tfpica: primero se realiza un cambio en una parte de la estructura del sistema de ontologfa en cuestion. A continuacion, dicho cambio debe detectarse y los mapeos necesitan una actualizacion. En una realizacion se imponen una o mas condiciones para aplicar dicho cambio.
Un cambio en (una parte de) la estructura del sistema de ontologfa puede constituir un unico cambio o un conjunto de varios cambios. En una realizacion el cambio comprende un reetiquetado de una parte de la estructura del sistema de ontologfa. El cambio tambien puede ser anadir otra estructura a parte de la estructura del sistema de ontologfa, no siendo dicha otra estructura parte de la estructura del sistema de ontologfa antes del cambio. El cambio comprende insertar una estructura adicional en una parte de la estructura del sistema de ontologfa, con lo que esa estructura adicional no es parte de la estructura del sistema de ontologfa antes del cambio. El cambio tambien puede comprender el borrado de parte de la estructura del sistema de ontologfa.
En otro aspecto, se proporciona un programa ejecutable en un dispositivo programable que contiene instrucciones, que, al ejecutarse, realizan el metodo que figura anteriormente.
En un aspecto adicional se proporciona un dispositivo para modificar un mapeo de al menos una ruta de aplicacion de un sistema de datos a una ruta conceptual de un sistema de ontologfa, por lo que la ruta de aplicacion direcciona una parte de la estructura de dicho sistema de datos y la ruta conceptual direcciona una parte de la estructura del sistema de ontologfa. El dispositivo comprende unos medios para detectar un cambio en una parte de la estructura del sistema de ontologfa que esta direccionando una o mas de dichas rutas conceptuales y medios para actualizar los mapeos para reflejar el cambio en la parte de la estructura del sistema de ontologfa. Tambien pueden producirse las combinaciones de estos posibles cambios, como apreciaran los expertos en la materia.
En una realizacion preferida, el dispositivo esta dispuesto para identificar y almacenar la informacion sobre la version del sistema de ontologfa.
Breve descripcion de los dibujos
La figura 1 ilustra en la parte superior un patron semantico que podna ser util para anotar el esquema de datos logico en la parte inferior de la figura
La figura 2 representa una vista general de las entradas y las salidas del motor de traduccion.
La figura 3 ilustra un tipo de hecho que puede desplazarse en dos direcciones, indicando dos rutas.
La figura 4 ilustra un cambio que comprende un reetiquetado, un anadido, una insercion y un borrado, respectivamente.
La figura 5 ilustra un patron de semantica simple para expresar que las personas pueden tener nombres.
La figura 6 ilustra el patron semantico de la figura 5 despues de aplicar un registro de cambios para refinar el concepto nombre.
La figura 7 ilustra un patron semantico para expresar que las personas pueden tener nombres y apellidos.
La figura 8 ilustra el patron semantico de la figura 7 despues de aplicar un registro de cambios para distribuir la semantica sobre tanto los terminos como los roles.
La figura 9 ilustra el patron semantico de la figura 6 despues de aplicar un registro de cambios para distribuir la semantica sobre tanto los terminos como los roles.
La figura 10 ilustra un patron semantico para expresar que las personas son parte de un determinado grupo, y este grupo se localiza en una direccion determinada.
La figura 11 ilustra el patron semantico de la figura 10 despues de aplicar un registro de cambios para mover las relaciones.
La figura 12 ilustra un patron semantico para expresar que un grupo tiene una lmea de direccion y un pafs.
La figura 13 ilustra el patron semantico de la figura 12 despues de aplicar un registro de cambios para anadir una direccion de concepto que consiste en una lmea de direccion y un pafs.
La figura 14 ilustra un patron semantico para expresar que una persona tiene una direccion que tiene una lmea de direccion.
La figura 15 ilustra el patron semantico de la figura 14 despues de aplicar un registro de cambios para cortocircuitar el concepto de direcciones.
La figura 16 ilustra un patron semantico despues de aplicar un registro de cambios para el rol/co-rol de una persona que tenga una direccion en una persona localizada en una direccion.
5
10
15
20
25
30
35
40
45
50
55
60
65
La figura 17 ilustra el patron semantico de la figura 12 despues de aplicar un registro de cambios para renombrar el termino grupo por el termino persona.
Descripcion detallada de la invencion
Las ontolog^as definen, en general, representaciones compartidas por dos aspectos esenciales y duales de la semantica de un dominio, es decir, una semantica formal de informacion que permita el procesamiento de la informacion por un ordenador y una semantica del mundo real que permita enlazar el contenido procesable por maquina con un significado para los seres humanos sobre la base de las terminologfas consensuales y del lenguaje natural.
El enfoque de representacion de ontologfas introducido en la presente invencion adopta un enfoque de modelado orientado a los hechos. En este enfoque, los hechos se consideran la unidad de comunicacion y, por lo tanto, construyen representaciones de la semantica a partir de la abstraccion de estos hechos observados en los tipos de hecho. Los hechos representan objetos (entidades o valores) que juegan un cierto rol (parte en la relacion). Esto es diferente de los enfoques basados en los atributos tal como el modelado orientado a objetos, en el que el dominio esta representado por la abstraccion de los tipos de datos de los objetos observados.
Un sistema de datos se define por la combinacion de una parte intensional y extensional. Su definicion intensional prescribe las limitaciones de los elementos de datos en forma de tipos de datos (por ejemplo, numeros enteros, cadenas) y las relaciones entre los mismos (por ejemplo, la multiplicidad). Una definicion extensional prescribe que los elementos de datos pertenecen a que tipos de datos. Un sistema de datos puede anotarse por una ontologfa y puede considerarse como una aplicacion que compromete a la ontologfa. Una aplicacion compromete a un sistema de ontologfa si el sistema de datos esta usando los mapas en el sistema de ontologfa. Un mapeo de este tipo se realiza por rutas de aplicacion de mapeo que direccionan una parte de la estructura del sistema de datos. Un ejemplo de un sistema de datos es una base de datos relacional. En una base de datos relacional un ejemplo de una ruta de aplicacion podna direccionar un atributo espedfico en una tabla espedfica. La parte intensional se define mediante su esquema. La parte extensional se define mediante su poblacion. Otros ejemplos de sistemas de datos incluyen XML y su esquema correspondiente, los mensajes EDI, etc. El sistema de ontologfa tambien puede manejar los sistemas de datos para los que la parte intencional no esta disponible, por ejemplo, XML que no tiene un esquema correspondiente. Por ejemplo, en un archivo XML una ruta de aplicacion podna ser una XPath.
El sistema de ontologfa separa la representacion de la semantica del dominio y la anotacion de la aplicacion con esta semantica en tres capas separadas: base de lexon, base de patron, capa de compromiso.
Un lexon es un quintuple que define un tipo de hecho binario plausible dentro de un cierto contexto. El quintuple se define como {Contexto, termino de cabecera, rol, co-rol, termino de cola}. El rol, y su inverso el co-rol, define la relacion conceptual entre el termino de cabecera y de cola. Intuitivamente un lexon puede leerse como: dentro del contexto, el termino de cabecera puede tener una relacion con el termino de cola en el que juega un rol, y a la inversa, en el que el termino de cola juega un co-rol correspondiente.
Un contexto en un lexon proporciona una referencia para uno o mas recursos lexicos y/o partes de un recurso lexico (tal como los documentos) a partir del que se ha obtenido el lexon. Los contextos son importantes para evitar las ambiguedades lexicas de los terminos dentro de los lexones, ya que el significado de los terminos puede variar de acuerdo con el contexto.
Los lexones como tales no tienen una direccion de lectura, sin embargo, cuando se construye una ruta se les pueden proporcionar una de dos direcciones, ya sea empezando por el termino de cabecera o el termino de cola.
Una base de lexon se define como un conjunto de lexones. El objetivo de la base de lexon es proporcionar un recurso compartido y en evolucion que se use para llegar a un entendimiento comun y acordado sobre el vocabulario de ontologfa y por lo tanto se dirige al entendimiento humano, asociando terminos del lenguaje natural. La base de lexon refleja la estructura sintactica del sistema de ontologfa.
Una ruta conceptual en una base de lexon se define por un par de terminos de contexto o una concatenacion finita de lexones en esa base de lexon. En este ultimo caso tambien se impone una direccion de lectura espedfica. Una ruta conceptual puede ser un solo concepto (por ejemplo, la entrega), un lexon (por ejemplo, la fecha de entrega) o una agrupacion de diferentes lexones (por ejemplo, el dfa de la fecha de la fecha y la hora de entrega del envfo). Por lo tanto, las rutas conceptuales son capaces de direccionar las partes de la estructura del sistema de ontologfa. Las rutas conceptuales se usan en los patrones para definir las restricciones semanticas y en los compromisos para definir los mapeos.
Un patron semantico se define por una seleccion significativa de las rutas conceptuales en una base de lexon espedfica mas un conjunto de restricciones semanticas. Cada restriccion semantica tiene cierto tipo y se expresa como una recopilacion de conjuntos de rutas conceptuales. La figura 1 ilustra un patron semantico en la notacion ORM. Incluye diferentes rutas conceptuales. Por ejemplo, desde la parte inferior derecha del termino Apellido hasta
5
10
15
20
25
30
35
40
45
50
55
60
65
la parte superior izquierda del termino Pa^s, se verbaliza la ruta conceptual: Apellido parte del Nombre que identifica la Persona que reside en el Pafs. Una base de patron se define por un conjunto de patrones semanticos.
Un compromiso de una aplicacion informatica para un sistema de ontolog^a se define por una seleccion de partes de patrones semanticos de la base de lexon en el sistema de ontologfa, un conjunto de restricciones semanticas sobre estos patrones y un conjunto de mapeos que se mapean desde el sistema de datos usado por la aplicacion al sistema de ontologfa. Mas precisamente, las rutas de aplicacion del sistema de datos se mapean a las rutas conceptuales en estos patrones. La capa de compromiso se define por el conjunto de todos los compromisos.
Cada compromiso individual dentro de la capa de compromiso es una representacion de la semantica de un sistema de datos espedfico en terminos de la base de lexon. Los patrones pueden reutilizarse a traves de compromisos si se seleccionan de la misma base de patron. Si se hace, el sistema de ontologfa establece la interoperabilidad semantica entre los sistemas de datos y las aplicaciones en general (por ejemplo, los agentes de software y los servicios web).
Las reglas restringen y atribuyen interpretaciones espedficas a un subconjunto seleccionado de patrones contenidos dentro de la base de patron, por ejemplo, cada Persona tiene al menos una direccion. Como tal, cada regla de compromiso individual representa la semantica de una aplicacion espedfica.
Las rutas de aplicacion que direccionan la parte de la estructura del sistema de datos pueden mapearse en rutas conceptuales. Se requieren mapeos para crear de manera automatica las transformaciones de valor de datos entre un sistema de datos estructurado y un sistema de ontologfa estructurado. Dado un sistema de datos de origen y un sistema de datos de destino, y sus respectivos mapeos para una parte compartida de un sistema de ontologfa, es posible crear de manera automatica unas transformaciones de valor de datos entre dichos sistemas de datos de origen y de destino. La transformacion se realiza de manera automatica mediante un motor de traduccion. El motor de traduccion funciona analizando un compromiso de origen y de destino, que contiene los mapeos de las rutas de aplicacion de un sistema de datos en las rutas conceptuales de un sistema de ontologfa, y lee los sfmbolos de datos del sistema de datos de origen y escribe los sfmbolos traducidos en el sistema de datos de destino. La figura 2 proporciona una vision general de las entradas y salidas del motor de traduccion. El motor en sf mismo esta compuesto de:
• un analizador que construye un arbol sintactico a partir de un compromiso textual;
• un lector que se encarga de consultar un sistema de datos;
• un escritor que se encarga de la actualizacion y la creacion de datos en un sistema de datos;
• un motor de secuenciacion de ordenes accesible por el lector y el escritor.
Las secuenciaciones de ordenes personalizadas pueden escribirse por los usuarios del motor que permiten la modificacion del comportamiento en tiempo de ejecucion sin cambiar el propio motor. El motor de traduccion usa un enfoque de impulso y de arrastre en funcion del tipo de sistema de datos.
Enfoque de impulso
En el enfoque de impulso el Lector comienza a leer el sistema de datos de origen e impulsa los sfmbolos de datos hacia el sistema de almacenamiento, que se aceptan inmediatamente por el Escritor y se escriben en el sistema de datos de destino. En efecto, el sistema de datos de origen esta impulsando sus datos en el sistema de datos de destino. El enfoque de impulso se usa para los sistemas de datos de origen con estructura de arbol, tal como XML. En el compromiso de origen los mapeos se procesan en el orden en que se listan. El primer mapeo se asume para que apunte al elemento rafz.
Los mapeos deben estar en la siguiente forma:
map “/a” on A.
map “/a/b” on B de A.
map “/a/b/c” on C deB deA.
map “/a/d” on D de A.
La palabra clave 'map' indica que esta declaracion es un mapeo. La parte izquierda del mapeo es una ruta de aplicacion expresada en un lenguaje de ruta que puede usarse para direccionar los elementos en el sistema de datos (por ejemplo, XPath). La ruta de aplicacion esta encerrada entre comillas dobles.
La ruta de aplicacion contiene suficiente informacion para construir una consulta procesable por un motor de consulta que soporte el formato de datos del sistema de datos. El Lector envfa estas consultas al motor de consulta adecuado. Por ejemplo, en XML, las XPaths pueden procesarse como consultas por un motor Xpath como Xalan. La misma ruta de aplicacion se usa tambien por el Escritor para escribir los datos en la localizacion a la que se dirige la
5
10
15
20
25
30
35
40
45
50
55
60
65
ruta.
La palabra clave 'on' separa las partes izquierda y derecha de la declaracion de mapeo. A la derecha esta escrita una ruta conceptual, construida usando los s^bolos del sistema de ontolog^a. Cada declaracion termina con un punto.
Los mapeos se procesan en el orden dado. Las rutas conceptuales estan relacionadas entre sf por este orden. En el ejemplo anterior la instancia para el concepto A es la misma en cada uno de los mapeos. Esto se conoce porque el primer elemento en la ruta de aplicacion es tambien el mismo y porque esta apuntando al elemento rafz. Otros elementos no rafz pueden repetirse y cada vez se instancia el concepto correspondiente. Por ejemplo, cuando hay tres elementos b, se instancian tres conceptos B correspondientes. Para cada uno de los mapeos pueden instanciarse cero o mas rutas conceptuales, en funcion del numero de elementos en el sistema de datos de origen.
A continuacion esta un ejemplo de XML que es valido para los mapeos anteriores.
<a>
- <b>
- <c> texto </c>
- </b>
- <b>
- <c> texto2 </c>
- </b>
- <b>
- <c> texto3 </c>
- </b>
</a>
Esto instancia las siguientes rutas (las instancias de los conceptos estan entre parentesis, donde las entidades se identifican por un numero prefijado con el sfmbolo @, y los valores se muestran entre comillas dobles):
A (@ 1).
B (@ 1) of A (@ 1).
B (@ 2) of A (@ 1).
B (@ 3) of A (@ 1).
C (“texto”) of B (@ 1) of A (@ 1).
C (“texto2”) of B (@ 2) of A (@ 1).
C (“texto3”) of B (@ 3) of A (@ 1).
El escritor usa el reverso de este proceso y construye los datos para el sistema de datos de destino a partir de estas rutas instanciadas. El escritor consulta que mapeo corresponde a la ruta instanciada y construye los elementos en el sistema de datos.
Enfoque de arrastre
Como alternativa, un enfoque de arrastre permite al Escritor decidir que datos necesita del Lector. En este caso, el Escritor pregunta al Lector por cada pieza de informacion que necesita. El Escritor esta arrastrando los datos del lector, que los coloca en el almacenamiento, listos para que acceda el Escritor. El enfoque de arrastre se usa para los sistemas de datos basados en graficas, tales como las bases de datos relacionales. En contraposicion con el enfoque de impulso, el enfoque de arrastre comienza con el escritor que solicita las rutas instanciadas del lector por sus mapeos.
Dadas unas consultas conceptuales de compromiso ontologico se ejecutan en cualquier sistema de datos que esta anotado correctamente por ese compromiso. Una consulta conceptual es una construccion de lenguaje expresada en terminos de una o mas rutas conceptuales en un compromiso. Dados los mapeos entre las rutas conceptuales y las rutas de aplicaciones en un compromiso, las consultas conceptuales pueden ejecutarse como consultas logicas en el sistema de datos de compromiso. Esto se hace traduciendo (las rutas conceptuales en) la consulta conceptual en una consulta logica en terminos de las rutas de aplicacion del sistema de datos. Una consulta logica es una consulta dentro del sistema de datos. Por ejemplo, una consulta logica en una base de datos relacional se expresana en SQL.
En una realizacion se especifican los compromisos ontologicos en el lenguaje natural controlado Q-RIDL (Omega- RIDL). El lenguaje describe reglas semanticas en terminos de rutas conceptuales en el que las etiquetas de rol y co- rol necesitan interpretarse como una relacion ontologica. Q-RIDL es tanto una consulta conceptual como un lenguaje de especificacion de compromiso.
Los sistemas y los metodos de la invencion pueden verse como una mejora adicional del enfoque DOGMA para el desarrollo de la mediacion de ontologfa guiada de los agentes. DOGMA (R. Meersman., Proc. of the International
5
10
15
20
25
30
35
40
45
50
55
60
65
Symposium on Methodologies for Intelligent Systems (ISM IS), paginas 30-45, 1999) es un enfoque ontologico y un marco que no se restringe a un lenguaje de representacion espedfico. Las realizaciones de la presente invencion aplican el marco DOGMA a la ontologfa sobre la base del mapeo de datos.
La figura 3 ilustra una relacion entre dos conceptos Producto y Orden. Cada lexon puede recorrerse en dos direcciones, denotando dos rutas: un Orden para un producto, y un producto que tiene un Orden.
Las rutas conceptuales pueden concatenarse para formar rutas compuestas. Estas concatenaciones pueden formalizarse de manera adicional con reglas y limitaciones, que restringen el posible uso de los conceptos y las relaciones en la ontologfa.
La anotacion se expresa en Q-RIDL. La figura 1 ilustra, en la parte superior, un patron semantico que podna ser usado para anotar el esquema logico de datos en la parte inferior de la figura.
Cada sfmbolo relevante en la instancia de esquema de datos logicos se anota por una ruta conceptual significativa en el patron. Si un sfmbolo relevante no puede anotarse por la version de patron actual, el patron se cambia de tal manera que la nueva version de patron permite anotar los sfmbolos pendientes.
En el ejemplo anterior, todos los atributos de la tabla Personas (las rutas de aplicacion) pueden mapearse por rutas conceptuales en el patron. Por lo tanto, se puede leer:
- map “Gente.nombre” on “Nombre parte del Nombre que identifica a la Persona”
- map “Gente.apellido” on “Apellido parte del Nombre que identifica a la Persona”
- map “Gente.ciudad” on “Ciudad es el lugar de nacimiento de la Persona”
- map “Gente.pafs” on “Pafs donde reside la Persona”
El ejemplo anterior es trivial, ya que los terminos de los sfmbolos de atributos son interpretables de manera intuitiva. Sin embargo, en escenarios del mundo real el significado de los sfmbolos en el esquema logico esta, en general, implfcito. Incluso en este ejemplo: aunque los significados independientes de los sfmbolos ciudad, pafs y persona son intuitivamente obvios, su interrelacion no lo es. Pafs y ciudad parecen no estar relacionados en absoluto, ya que tambien se puede deducir a partir de los valores de los atributos. Por otra parte, nombre y apellido parecen estar relacionados entre sf de manera indirecta a traves de la relacion (parte de) metommica con nombre.
El sistema de anotacion anterior funciona para diferentes tipos de tecnologfas de gestion de datos, incluyendo las tablas y las columnas relacionales, las clases orientadas a objetos, o las etiquetas XML. Dada una ontologfa compartida, las consultas en un esquema de datos logico con anotaciones pueden traducirse de manera automatica a consultas en cualquier otro esquema de datos logico que se anota con esta ontologfa. Por lo tanto, esto proporciona un enfoque universal para la integracion de datos. Ademas, como las anotaciones estan cerca del lenguaje natural, el significado de los sfmbolos en los esquemas puede describirse e interpretarse por el usuario final lego en esta materia.
Evolucion
La implementacion de un cambio en un sistema de ontologfa es un proceso diffcil que necesita muchas diferentes sub-actividades: propagacion del cambio, reestructuracion y gestion de la inconsistencia.
Con este fin, el dispositivo de acuerdo con la presente invencion comprende en una realizacion preferida una capa de versionado. Dicha capa de versionado proporciona toda la funcionalidad para identificar y almacenar las versiones de ontologfa y los registros de cambios. Los registros de cambios realizan un seguimiento de los cambios necesarios para determinar una version del sistema de ontologfa empezando a partir de una version anterior. Un editor de ontologfas puede soportar la edicion versionada de las ontologfas con una interfaz grafica.
Toda la informacion sobre los cambios realizados se sigue y se registra en un registro de cambios, tambien denominado como un registro de version. Un registro de cambios entre una version K del sistema de ontologfa y una version K + 1 del sistema de ontologfa se define como una secuencia de operaciones de cambio que se realizan en la version K, con el fin de resultar en la version K + 1.
Los ejemplos de los cambios a nivel de base de lexon se reetiquetan, insertando o anadiendo lexones a o eliminando lexones de la estructura del sistema de ontologfa existente. Ejemplos de operadores de cambio en el nivel de base de patron son crear o eliminar un patron. Ejemplos de operadores de cambio en el nivel de la capa de compromiso son crear, revisar o eliminar una ruta o una regla. Esto se ilustra en la figura 4. La figura muestra de arriba hacia abajo cuatro tipos de cambios que pueden ocurrir en un sistema de ontologfa. El tipo reetiquetar incluye cualquier renombrado de un termino para un concepto (nodo) o relacion (borde) en el sistema de ontologfa. En el primer ejemplo, antes del cambio un concepto se denomina por un termino ‘B’. Despues del cambio el mismo concepto se denomina por un termino B’’. En el segundo ejemplo, la relacion denominada por ‘a' entre los conceptos (denominada por los terminos ‘A’ y B’) consigue un nuevo termino ‘a”.
5
10
15
20
25
30
35
40
45
50
55
60
65
El tipo anadir incluye cualquier cambio que se asocia a una nueva estructura del sistema de ontolog^a existente. Por ejemplo, antes del cambio, una parte del sistema de ontologfa consiste en un concepto denominado por el termino 'A'. Despues del cambio se anade una nueva estructura que incluye los conceptos denominados por los terminos ‘B’ y ’C’ y las relaciones denominadas por 'a' y 'b', respectivamente, a este concepto ya existente.
El tipo insertar incluye cualquier cambio que se inserta en una nueva estructura entre dos partes existentes del sistema de ontologfa. Por ejemplo, en este caso se inserta un nuevo concepto denominado por el termino ‘B’ y la relacion denominada por C entre los conceptos existentes ‘A’ y ‘C’. El tipo insertar se aplica en los ejemplos tratados a continuacion Mover Relacion, Conceptualizacion, Cortocircuito.
El tipo borrar incluye cualquier cambio que elimina una parte de la estructura del sistema de ontologfa. Por ejemplo, la eliminacion de una relacion que se denomina por el termino 'a' entre los conceptos ‘A’ y ‘B’.
Actualizar mapeos basandose en cambiar el sistema de ontologia
Un mapeo de un sistema de datos a una version K del sistema de ontologfa podna romperse cuando se cambia la version K del sistema de ontologfa a la version K + 1, porque las rutas conceptuales usadas en el mapeo se reestructuran, se borran o se desaprueban. Por lo tanto cualquier mapeo con la version K del sistema de ontologfa debena adaptarse a la nueva version K + 1 del sistema de ontologfa. El registro de cambios almacena la secuencia de todas las operaciones (cambios) entre dos versiones de sistema de ontologfa. El registro de cambios puede usarse de este modo para diferentes fines tales como para identificar conflictos o divergencias de significado. En el ejemplo anterior, el cambio de sfmbolo “Persona” a “Individual” desencadena un cambio en el mapeo en el que ha estado involucrado Persona:
- map “Gente.nombre” on “Nombre parte del Nombre que identifica al Individuo”
- map “Gente.apellido” on “Apellido parte del Nombre que identifica al Individuo”
- map “Gente.ciudad” on “Ciudad es el lugar de nacimiento del Individuo”
- map “Gente.pafs” on “Pafs donde reside del Individuo”
Usando el registro de cambios de otros conflictos puede identificarse cuando mezclar las evoluciones paralelas de una version ontologfa. Para cada uno de los conflictos, la presente invencion proporciona un conjunto de estrategias de resolucion alternativas.
Derivar un conjunto de patrones reutilizables en la Ontologia
Dado un conjunto de ontologfas similares, las partes comunes pueden recopilarse y abstraerse de manera automatica en patrones que pueden reutilizarse para fines posteriores. Por ejemplo, diferentes organizaciones pueden reutilizar de manera independiente el patron de concepto de una tarea de trabajo para anotar sus esquemas de datos acerca de la entrega.
Un registro de cambios es una trascripcion de un proceso de evolucion de ontologia que esta representada por una secuencia ordenada de operaciones de ontologia. Cada registro de cambios se limita a las operaciones de algunas clases de operadores espedficos. Algunos operadores tienen pre y post-condiciones y cada operador pertenece a una clase de operador. Tambien se registran las operaciones fallidas, incluyendo las condiciones insatisfechas que provocaron el fallo.
Un operador de evolucion de ontologia atomico C define la semantica de cambio de una ontologia en terminos de las siguientes propiedades: una condicion previa PreCond (C) para un operador de cambio C es una condicion que debe mantenerse en una ontologia O con el fin de que C pueda aplicarse a esa ontologia O, y una postcondicion PostCond (C) para un operador de cambio C es una condicion que debe mantenerse en una ontologia O’ que es el resultado de aplicar C a la ontologia O.
Un operador de evolucion de ontologia compuesto se define por una secuencia ordenada de operadores de evolucion de ontologia atomicos. Una operacion de evolucion de ontologia es una ocurrencia espedfica de un operador de evolucion de ontologia.
En la presente invencion, los cambios proporcionados se detectan para la anotacion de uno o mas sistemas de informacion, comprendiendo dichos cambios un conjunto de operadores compuestos que agrupan un numero de operadores atomicos de los patrones semanticos y los operadores equivalentes para los mapeos en los compromisos, en los que dichos operadores compuestos se anaden al registro de cambios.
A continuacion, se explican las realizaciones espedficas de las operaciones y los operadores del cambio por medio de ejemplos. Otros conjuntos de operadores pueden recibirse por el registro de cambios para proporcionar una secuencia de cambios. Cada uno de los operadores es una variacion de los tipos de cambios mencionados anteriormente: reetiquetar, insertar, anadir y eliminar.
Para mayor comodidad del lector, el termino de cabecera y de cola se inician con una letra mayuscula, y los terminos rol/co-rol estan en letras minusculas.
5
10
15
20
25
30
35
40
45
50
55
60
65
En una realizacion, dichos operadores compuestos comprenden unos operadores atomicos para refinar los conceptos de refinacion y actuar sobre la parte de la ruta conceptual de los mapeos correspondientes. El refinado es un ejemplo del tipo anadir.
Considerese el ejemplo ilustrado en las figuras 5 y 6. La figura 5 muestra un patron semantico simple para expresar que las personas pueden tener nombres. Esto esta mapeado para un ejemplo XML usando las siguientes expresiones Q-RIDL:
map "concat (/persona/pname/fname, /persona/pname/lname)" on Nombre de la Persona.
Debido a que el patron semantico es demasiado limitado para expresar la informacion de, por ejemplo, un nuevo socio de negocios, debe ampliarse para incluir tambien el nombre y el apellido de manera explfcita. Esto puede lograrse usando el siguiente registro de cambios:
introduceTerm ("Nombre")
defineDifferentia ("Nombre", "consiste en", "parte de", "Nombre") introduceTerm ("Apellido")
defineDifferentia ("Nombre", "consiste en", "parte de", "Apellido") introduceTerm (X)
defineDifferentia ("Nombre", r, r' , X)
La aplicacion de estas operaciones en el patron semantico de la figura 5 lleva al patron semantico de la figura 6. Este patron semantico requiere un nuevo compromiso con los siguientes mapeos que reemplazan a los anteriores:
map "/persona/pname/fname"
on Nombre parte del Nombre de la Persona.
map "/persona/pname/lname"
on Apellido parte del Nombre de la Persona. map "/persona/pname/xxx" on X r' Nombre de la Persona.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador puede definirse de la siguiente manera:
refine (X, r, r', Z1, . . . Zn)
+ introduceTerm (Z1)
+ defineDifferentia (X, r, r', Z1)
+ ...
+ introduceTerm (Zn)
+ defineDifferentia (X, r, r', Zn)
Aplicado en el ejemplo, esto proporciona el siguiente operador compuesto para el patron semantico en el registro de cambios:
refine ("Nombre", "consiste en", "parte de", "Nombre", "Apellido", "X")
+ introduceTerm ("Nombre")
+ defineDifferentia ("Nombre", "consiste en", "parte de", "Nombre")
+ introduceTerm ("Apellido")
+ defineDifferentia ("Nombre", "consiste en", "parte de", "Apellido")
+ introduceTerm ("X")
+ defineDifferentia ("Nombre", "consiste en", "parte de", "X")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
map "concat (/persona/pname/fname, /persona/pname/lname)" on Nombre de la Persona.
El operador expresa que esta ruta conceptual se ha refinado, y pregunta al usuario como realizar el refinamiento:
5
10
15
20
25
30
35
40
45
50
55
60
65
map "/persona/pname/fname"
on Z1... Zn ? r' Nombre de la Persona.
map "/persona/pname/lname"
on Z1... Zn ? r' Nombre de la Persona.
Observese que el operador solo permite el refinamiento usando la misma relacion, es decir, en el caso del ejemplo: consiste en/parte de. Una multitud de operadores “refine” pueden aplicarse, por ejemplo, “split” y “atribute”.
Observese tambien que la ruta de aplicacion de XML en este ejemplo es una funcion agregada (concat). El algoritmo usado puede identificarles y por lo tanto, dividirlos perfectamente en mapeos separados (basandose en el operador “ refine”).
Ejemplo 2: Rolificar conceptos
En otra realizacion, los operadores compuestos comprenden unos operadores atomicos para distribuir la semantica sobre tanto los terminos como los roles. Este es un ejemplo del tipo reetiquetar.
Considerese el ejemplo ilustrado en las figuras 7 y 8. La figura 7 describe el patron semantico tal cual. El mapeo correspondiente es de la siguiente manera:
map "/persona/Nombre/fname" on Nombre de la Persona. map "/persona/Nombre/lname" on Apellido de la Persona.
Debido a que se prefiere distribuir la semantica sobre tanto los terminos como los roles, el patron semantico necesita evolucionar usando el siguiente registro de cambios:
defineDifferentia ("Persona", "tiene nombre", "nombre de", "Nombre") dropDifferentia ("Persona", "tiene", "de", "Nombre")
defineDifferentia ("Persona", "tiene apellido", "apellido de", "Nombre") dropDifferentia ("Persona", "tiene", "de", "Apellido")
Esto resulta en el patron de la figura 8, y debena resultar en mapeos actualizados en el compromiso de la siguiente manera:
map "/persona/Nombre/fname" on Nombre nombre de la Persona. map "/persona/Nombre/lname" on Nombre apellido de la Persona.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador se define de la siguiente manera:
rolify (X, r' , r, Y, a' , a)
+ defineDifferentia (X, a', a, Y)
+ dropDifferentia (Y, r', r, X) o
rolify (X, r', r, Y)
+ rolify (X, r', r, Y, "X de", "tiene X")
Aplicado en el ejemplo, esto proporciona el siguiente elemento en el registro de cambios:
rolify ("Nombre", "de", "tiene", "persona", "nombre de", "tiene nombre")
+ defineDifferentia ("Nombre", "nombre de", "tiene nombre", "Persona")
+ dropDifferentia ("Nombre", "de", "tiene", "Persona") o
rolify ("Nombre", "de", "tiene", "Persona")
+ defineDifferentia ("Nombre", "Nombre de", "tiene nombre", "Persona")
+ dropDifferentia ("Nombre", "de", "tiene", "Persona")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
5
10
15
20
25
30
35
40
45
50
55
60
65
map "/persona/pname/fname" on Nombre de la Persona.
El operador expresa que esta ruta conceptual se ha rolificado, y realiza la operacion
map /persona/Nombre/fname on Nombre nombre de la Persona
Considerese otro ejemplo ilustrado en las figuras 6 y 9. La figura 6 describe el patron semantico tal cual. El mapeo correspondiente es de la siguiente manera:
map "/persona/nombre/fname"
on Nombre parte del Nombre de la Persona.
map "/persona/nombre/lname"
on Apellido parte del Nombre de la Persona. map "/persona/nombre/xxx" on X r' Nombre de la persona.
Debido a que se prefiere para distribuir la semantica sobre tanto los terminos como las funciones, el patron semantico necesita evolucionar usando el siguiente registro de cambios:
defineDifferentia ("Persona", "tiene nombre", "nombre de", "Nombre") dropDifferentia ("Nombre", "consiste en", "parte de", "Nombre") defineDifferentia ("Persona", "tiene apellido", "apellido de", "Nombre") dropDifferentia ("Nombre", "consiste en", "parte de", "Apellido") defineDifferentia ("Persona", "tiene X", "X de", "Nombre") dropDifferentia ("Nombre", r, r' , X)
dropDifferentia ("Persona", "tiene", "de", "Nombre")
Esto resulta en el patron de la figura 9, y debena resultar en unos mapeos actualizados en el compromiso de la siguiente manera:
map "/persona/nombre/fname" on Nombre nombre de la Persona. map "/persona/nombre/lname" on Nombre apellido de la Persona. map "/persona/nombre/xxx" on Nombre X de la Persona.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s). El nuevo operador se define de la siguiente manera:
rolify (X, r', r, Y, a', a, Z)
+ definedifferentia (Z, "tiene X", "X de", Y)
+ dropdifferentia (Y, r', r, Z)
[+ dropdifferentia (Z, a, a', Y)]
Aplicado en el ejemplo, se tiene el elemento siguiente en el registro de cambios:
+ rolify ("Nombre", "parte de", "parte de", "Nombre", "de", "tiene", "Persona")
+ definedifferentia ("Persona", "tiene nombre", "nombre de", "nombre de")
+ dropdifferentia ("Nombre", "consiste en", "parte de", "Nombre")
[+ dropdifferentia ("Persona", "tiene", "de", "Nombre")]
+ rolify ("Apellido", "parte de", "parte de", "Nombre", "de", "tiene", "Persona")
+ definedifferentia ("Persona", "tiene el apellido", "apellido de", "nombre")
+ dropdifferentia ("Nombre", "consiste en", "parte de", "Apellido")
[+ dropdifferentia ("Persona", "tiene", "de", "Nombre")]
+ rolify ("X", "parte de" "parte de", "Nombre", "de", "tiene", "Persona")
+ definedifferentia ("Persona", "tiene X", "X de", "Nombre")
+ dropdifferentia ("Nombre", "consiste en", "parte de", "X")
[+ dropdifferentia ("Persona", "tiene", "de", "Nombre")]
5
10
15
20
25
30
35
40
45
50
55
60
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
map "/persona/pname/fname"
on Nombre parte del Nombre de la Persona.
El operador expresa que esta ruta conceptual se ha rolificado, y realiza la operacion
map "/persona/nombre/fname" on Nombre nombre de la Persona.
Ejemplo 3: Mover relaciones
En una realizacion siguiente, dichos operadores compuestos comprenden unos operadores atomicos para mover las relaciones. Una relacion de movimiento combina los tipos insertar y borrar descritos anteriormente. Considerese el ejemplo ilustrado en las figuras 10 y 11. El patron semantico de la figura 10 explica que las personas son parte de un determinado grupo, y que este grupo se localiza en una direccion determinada. El patron se ha comprometido con los siguientes mapeos:
map "/.../direccion" on Direccion de Grupo.
Parecfa que se habfa realizado un error en el diseno del patron semantico, ya que la direccion debe ser en realidad la localizacion de la persona que es parte del grupo. Esto puede resolverse usando el siguiente registro de cambios:
defineDifferentia ("Persona", "localizado en", "localizacion de", "Direccion") dropDifferentia ("Grupo", "localizado en", "localizacion de", "Direccion")
El resultado es el patron semantico de la figura 11 y el compromiso correspondiente:
map "/.../direccion" on Direccion de la Persona.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador se define de la siguiente manera:
move (X, r', r, Y, Z)
+ defineDifferentia (X, r', r, Z)
+ dropDifferentia (X, r', r, Y)
que se ve de la siguiente manera para el ejemplo:
move ("Direccion", "localizacion de", "localizado de", "Grupo", "Persona")
+ defineDifferentia ("Direccion", "localizacion de", "localizado en", "Persona")
+ dropDifferentia ("Direccion", "localizacion de" "localizado en", "Grupo")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
map "/.../direccion" on Direccion del Grupo.
El operador expresa que esta ruta conceptual se ha movido, y realiza la operacion
map "/.../direccion" on Direccion de la Persona.
Relacionado con esto esta el nuevo operador de copia que se define de la siguiente manera:
copy (X, r', r, Y, Z)
defineDifferentia (X, r', r, Y, Z)
5
10
15
20
25
30
35
40
45
50
55
60
65
En una realizacion adicional, dichos operadores compuestos comprenden unos operadores atomicos para anadir conceptos. Los tipos insertar y borrar se combinan de este modo.
Considerese el ejemplo ilustrado en las figuras 12 y 13. Considerando el patron semantico de la figura 12 y el compromiso correspondiente:
map "/.../linea de direccion" on Linea de Direccion del Grupo. map "/.../pais_no:mbre" on Pais del Grupo.
Supongase que el pafs y la linea de direccion necesitan estar relacionados a traves de una nueva direccion de concepto. A continuacion la direccion sirve como conceptualizacion intermedia de la relacion entre pa^s y la linea de direccion; y el grupo respectivamente.
Esto puede resolverse usando el siguiente registro de cambios:
introduceTerm ("Direccion")
defineDifferentia ("Grupo", "se localiza en", "localizacion de", "Direccion") defineDifferentia ("Direccion", "consiste en", "parte de", "Linea de Direccion") dropDifferentia ("Grupo", "tiene", "de", "Linea de Direccion") defineDifferentia ("Direccion", "consiste en", "parte de", "Pais") dropDifferentia ("Grupo", "tiene", "de" "Linea de Direccion")
El resultado es el patron semantico de la figura 13 y el compromiso correspondiente:
map "/.../linea de direccion"
on la parte Linea Direccion de la localizacion de Direccion del Grupo. map "/.../pais_nombre"
on parte de Pais de la localizacion de Direccion del Grupo.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador se define de la siguiente manera:
conceptify (X, r'0, r0, Y, r'n, rn, Zn) introduceTerm (X)
defineDifferentia (X, r'0, r0, Y) move (Zn, r'n, rn, Y, X)
que se ve de la siguiente manera en el ejemplo:
conceptify ("Direccion", "localizacion de", "localizado en", "Grupo", "tiene", "de", "Linea de direccion", "tiene", "de", "Pais")
+ introduceTerm ("Direccion")
+ defineDifferentia ("Direccion", "localizacion de", "localizado en", "Grupo")
+ move ("Linea de direccion", "de", "tiene", "Grupo", "Direccion")
+ move ("Pais", "de", "tiene", "Grupo", "Direccion")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
map "/.../linea de direccion" on Linea de Direccion del Grupo.
El operador expresa que esta ruta conceptual se ha movido, y realiza la operacion
map "/.../direccion"
on Linea de Direccion de la localizacion de la Direccion del Grupo.
5
10
15
20
25
30
35
40
45
50
55
60
65
En otra realizacion, dichos operadores compuestos comprenden operadores atomicos para eliminar conceptos. De este modo, se combinan el tipo insertar y eliminar como se ha descrito anteriormente.
Considerese el ejemplo ilustrado en las figuras 14 y 15. Considerando el patron semantico de la figura 14 y el compromiso correspondiente:
map /persona/direccion/linea de direccion
on Linea de Direccion de localizacion de Direccion de la Persona
Supongase que la ruta mapeada “Lrnea de Direccion de localizacion de Direccion de la Persona” necesita simplificarse a “Lrnea de Direccion de localizacion de la persona”.
Esto puede resolverse aplicando el siguiente registro de cambios:
defineDifferentia ("Persona", "localizado en", "localizacion de", "Linea de Direccion")
dropDifferentia ("Direccion", "consiste en", "parte de", "Linea de Direccion") dropDifferentia ("Persona", "localizado en", "localizacion de", "Direccion")
El resultado es el patron semantico de la figura 15 y el compromiso correspondiente:
map "/persona/direccion/linea de direccion" on Linea de Direccion de localizacion de la persona
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador se define de la siguiente manera:
shortcircuit (X, r1, r'1, Y, r2, r'2, Z)
+ move (X, r1, r'1, Y, Z)
+ dropDifferentia (Y, r2, r'2, Z)
Que se ve de la siguiente manera en el ejemplo:
shortcircuit ("Persona", "localizado en", "localizacion de", "Direccion", "consiste en", "parte de", "Linea de Direccion")
+ move ("Persona", "localizado en", "localizacion de, "Direccion", "Linea de Direccion")
+ dropDifferentia ("Direccion", "consiste en", "parte de", "Linea de Direccion")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos: map "/.../linea de direccion"
on la Linea de direccion de localizacion de Direccion de la Persona.
El operador expresa que esta ruta conceptual se ha movido, y realiza la operacion map "/.../direccion"
on la localizacion la de Linea de direccion del Grupo.
Ejemplo 6: Renombrar el rol basico
En otro ejemplo mas, dichos operadores compuestos comprenden unos operadores atomicos para renombrar los roles y/o los co-roles. Este es otro caso en el que se produce el tipo reetiquetar.
Considerese el ejemplo ilustrado en la figura 16. El siguiente patron y el mapeado muestran la situacion de inicio:
map "/persona/direccion" on Direccion de la Persona.
Para hacer la semantica de este patron mas clara, se ejecuta el siguiente registro de cambios, por ejemplo, para hacer una diferencia con los diferentes tipos de localizaciones: “Persona nacida en/lugar de nacimiento de Direccion”, “Persona domiciliada en/domicilio de Direccion”,...
5
10
15
20
25
30
35
40
45
50
55
60
65
dropDifferentia ("Persona", "tiene", "de", "Direccion")
defineDifferentia ("Persona", "localizado en", "localizacion de", "Direccion")
El resultado de este registro de cambios se muestra en la figura 16, necesitando el siguiente mapeo correspondiente:
map "/persona/direccion"
on la localizacion de Direccion de la Persona.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador se define de la siguiente manera:
renameDifferentia (X, r1, r'1, Y, r2, r'2)
+ dropDifferentia (X, r1, r'1, Y)
+ defineDifferentia (X, r2, r'2, Y)
que se ve de la siguiente manera para el ejemplo:
renameDifferentia ("Persona", "tiene", "de", "Direccion", "localizado en", "Localizacion de")
+ dropDifferentia ("persona", "tiene", "de", "Direccion")
+ defineDifferentia ("Persona", "localizado en", "localizacion de", "Direccion")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
map "/persona/direccion" on Direccion de la Persona.
El operador expresa que en esta ruta conceptual se ha renombrado, y realiza la operacion
map "/persona/direccion"
on localizacion de Direccion de la Persona.
Ejemplo 7: Renombrar termino basico
En una realizacion, dichos operadores compuestos comprenden unos operadores atomicos para renombrar los terminos. Tambien en este caso se aplica el tipo reetiquetar.
Considerese el ejemplo ilustrado en la figura 12. El patron de la figura 12 y el mapeo muestran la situacion de inicio:
map "/.../linea de direccion" on la linea de Direccion del Grupo. map "/.../pais_nombre" on Pais del Grupo.
Para hacer la semantica de este patron mas clara, se ejecuta el siguiente registro de cambios:
dropDifferentia ("Grupo", "tiene", "de", "Linea de Direccion") dropDifferentia ("Grupo", "tiene", "de", "Pais")
defineDifferentia ("Persona", "tiene", "de", "Linea de Direccion") defineDifferentia ("Persona", "tiene", "de", "Pais")
El resultado de este registro de cambios se muestra en la figura 17.
Y esto necesita el siguiente mapeo correspondiente:
map "/.../linea de direccion" on Linea de direccion de la persona. map "/.../pais_nombre" on Pais de Persona.
La solucion proporcionada por la presente invencion es en primer lugar la introduccion de un operador compuesto para el patron semantico que puede incorporarse en el registro de cambios. El operador compuesto define una secuencia espedfica de los operadores atomicos. En segundo lugar, este operador compuesto necesita tener un
5
10
15
20
25
30
35
40
45
operador equivalente que opere sobre los mapeos en el compromiso(s).
El nuevo operador se define de la siguiente manera:
renameTerm (X, Y)
+ introduceTerm (Y)
+ move (Zn, r'n, rn, X, Y)
+ dropConcept (X)
con (Zn, r'n, rn,) estando todas las relaciones asociadas con el termino original X.
que se ve de la siguiente manera en el ejemplo:
renameTerm ("Grupo", "Persona")
+ introduceTerm ("Persona")
+ move ("Linea de Direccion", "de", "tiene", "Grupo", "Persona")
+ move ("Pais", "de", "tiene", "Grupo", "Persona")
+ dropConcept ("Grupo")
En cuanto a los mapeos, el operador actua sobre la parte de la ruta conceptual de los mapeos:
map "/.../linea de direccion" on Linea de direccion del Grupo.
El operador expresa que esta ruta conceptual se ha renombrado, y realiza la operacion:
map "/.../linea de direccion" on Linea de direccion de la persona. map "/.../pais_nombre" on Pais de la Persona.
Ha de observarse que la estructura de datos dentro de los ejemplos se especifica en XML, pero esto tambien puede ser una base de datos o cualquier otro formato de datos, tal como EDI, CSV o una base de datos SQL. Los metodos de la presente invencion pueden extenderse a cualquier sistema de informacion y a cualquier formato de datos.
Los sistemas y los metodos de la presente invencion tambien pueden aplicarse a los sistemas de ontologfa distribuidos.
Aunque la presente invencion se ha ilustrado por referencia a las realizaciones espedficas, sera evidente para los expertos en la materia que la invencion no esta limitada a los detalles de las realizaciones ilustrativas anteriores, y que la presente invencion puede realizarse con cambios y modificaciones diversos sin alejarse del alcance de las reivindicaciones. Las realizaciones presentes son, por lo tanto, para considerarse en todos los aspectos como ilustrativas y no restrictivas, indicandose el alcance de la invencion por las reivindicaciones adjuntas mas que por la descripcion anterior, y todos los cambios que entren dentro del significado y del intervalo de equivalencia de las reivindicaciones estan, por lo tanto, destinados a que esten abarcados por las mismas. En otras palabras, se contempla cubrir una y todas las modificaciones, variaciones o equivalentes que caigan dentro del alcance de las reivindicaciones y cuyos atributos esenciales se reivindican en esta solicitud de patente.
Claims (10)
- 51015202530354045505560REIVINDICACIONES1. Un metodo implementado por ordenador para modificar un mapeo desde al menos una ruta de aplicacion de un sistema de datos usado por una aplicacion informatica a una ruta conceptual de un sistema de ontologfa enlazado con dicho sistema de datos, direccionando dicha ruta de aplicacion una parte de la estructura de dicho sistema de datos y direccionando dicha ruta conceptual una parte de la estructura del sistema de ontologfa, comprendiendo dicho metodo las etapas de- detectar un cambio en una parte de la estructura de dicho sistema de ontologfa que esta direccionando una o mas de dichas rutas conceptuales, siendo dicho cambio un cambio a nivel de base de lexon o a nivel de base de patron, siendo dicha base de lexon un conjunto de lexones, definiendo cada lexon una relacion entre dos terminos en un contexto determinado, siendo dicha base de patron un conjunto de patrones semanticos definidos por una seleccion de rutas conceptuales en dicha base de lexon y un conjunto de restricciones semanticas en dichas rutas conceptuales seleccionadas, describiendose dicho cambio mediante una secuencia ordenada de primeros operadores que definen la informacion semantica sobre dicho cambio,- definir uno o mas segundos operadores que operan en dicho mapeo, siendo dicho uno o mas segundos operadores equivalentes a dicho uno o mas primeros operadores usados para describir dicho cambio en dicha parte de la estructura de dicho sistema de ontologfa,- actualizar dicho mapeo con dicho uno o mas segundos operadores equivalentes para reflejar el cambio en dicha parte de la estructura del sistema de ontologfa.
- 2. El metodo de acuerdo con la reivindicacion 1, en el que dicho cambio detectado se almacena en un registro de cambios.
- 3. El metodo de acuerdo con la reivindicacion 2, por el que se imponen una o mas condiciones para aplicar dicho cambio en dicho sistema de ontologfa.
- 4. El metodo de acuerdo con cualquiera de las reivindicaciones 1 a 3, en el que dicho cambio comprende un reetiquetado de parte de la estructura del sistema de ontologfa.
- 5. El metodo de acuerdo con cualquiera de las reivindicaciones anteriores, en el que dicho cambio comprende anadir otra estructura a parte de la estructura del sistema de ontologfa, no siendo dicha otra estructura parte de la estructura del sistema de ontologfa antes del cambio.
- 6. El metodo de acuerdo con cualquiera de las reivindicaciones anteriores, en el que dicho cambio comprende insertar una estructura adicional a una parte de la estructura del sistema de ontologfa, no siendo dicha estructura adicional parte de la estructura del sistema de ontologfa antes del cambio.
- 7. El metodo de acuerdo con cualquiera de las reivindicaciones anteriores, en el que dicho cambio comprende eliminar parte de la estructura del sistema de ontologfa.
- 8. Un programa, ejecutable en un dispositivo programable que contiene instrucciones, que, cuando las ejecuta el dispositivo programable, realizan el metodo de acuerdo con cualquiera de las reivindicaciones anteriores.
- 9. Dispositivo para modificar un mapeo desde al menos una ruta de aplicacion de un sistema de datos usado por una aplicacion informatica a una ruta conceptual de un sistema de ontologfa enlazado con dicho sistema de datos, direccionando dicha ruta de aplicacion una parte de la estructura de dicho sistema de datos y direccionando dicha ruta conceptual una parte de la estructura del sistema de ontologfa, comprendiendo dicho dispositivo medios para detectar un cambio en una parte de la estructura de dicho sistema de ontologfa que esta direccionando una o mas de dichas rutas conceptuales, siendo dicho cambio un cambio a nivel de base de lexon o a nivel de base de patron, siendo dicha base de lexon un conjunto de lexones, definiendo cada lexon una relacion entre dos terminos en un contexto determinado, siendo dicha base de patron un conjunto de patrones semanticos definidos por una seleccion de rutas conceptuales en dicha base de lexon y un conjunto de restricciones semanticas en dichas rutas conceptuales seleccionadas, describiendose dicho cambio mediante una secuencia ordenada de primeros operadores que definen la informacion semantica sobre dicho cambio, unos medios para definir uno o mas segundos operadores que operan en dicho mapeo, siendo dicho uno o mas segundos operadores equivalentes a dicho uno o mas primeros operadores usados para describir dicho cambio en dicha parte de la estructura de dicho sistema de ontologfa y unos medios para actualizar dicho mapeo con dicho uno o mas segundos operadores equivalentes para reflejar el cambio en dicha parte de la estructura del sistema de ontologfa.
- 10. Dispositivo de acuerdo con la reivindicacion 9, en el que dicho dispositivo esta dispuesto para identificar y almacenar informacion sobre la version de dicho sistema de ontologfa.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP09159178A EP2246810A1 (en) | 2009-04-30 | 2009-04-30 | Method for ontology evolution |
| EP09159178 | 2009-04-30 | ||
| PCT/EP2010/055620 WO2010125061A2 (en) | 2009-04-30 | 2010-04-27 | Method and device for ontology evolution |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2553971T3 true ES2553971T3 (es) | 2015-12-15 |
Family
ID=41165136
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES10717615.8T Active ES2553971T3 (es) | 2009-04-30 | 2010-04-27 | Método y dispositivo para la evolución ontológica |
Country Status (7)
| Country | Link |
|---|---|
| US (2) | US8849874B2 (es) |
| EP (2) | EP2246810A1 (es) |
| DK (1) | DK2425383T3 (es) |
| ES (1) | ES2553971T3 (es) |
| PL (1) | PL2425383T3 (es) |
| PT (1) | PT2425383E (es) |
| WO (1) | WO2010125061A2 (es) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9613138B2 (en) * | 2008-09-03 | 2017-04-04 | Hamid Hatami-Hanza | Unified semantic scoring of compositions of ontological subjects |
| US8560494B1 (en) * | 2011-09-30 | 2013-10-15 | Palantir Technologies, Inc. | Visual data importer |
| US9189531B2 (en) * | 2012-11-30 | 2015-11-17 | Orbis Technologies, Inc. | Ontology harmonization and mediation systems and methods |
| US9529904B2 (en) | 2013-06-18 | 2016-12-27 | International Business Machines Corporation | Utility-based ontology evolution |
| US10853741B2 (en) | 2013-12-16 | 2020-12-01 | MetaGovernance, Inc. | Information governance platform |
| EP3161685B1 (en) * | 2014-06-24 | 2022-06-08 | Google LLC | Processing mutations for a remote database |
| JP6482645B2 (ja) * | 2014-07-18 | 2019-03-13 | コンヴィーダ ワイヤレス， エルエルシー | Ｍ２ｍオントロジ管理および意味論的相互運用性 |
| WO2017040290A1 (en) * | 2015-08-28 | 2017-03-09 | Iqstrategix, Inc. | Knowledge acquisition, visualization and storage system |
| US9727554B2 (en) | 2015-11-24 | 2017-08-08 | International Business Machines Corporation | Knowledge-based editor with natural language interface |
| US20180357381A1 (en) * | 2017-06-09 | 2018-12-13 | Intelligent Medical Objects, Inc. | Method and System for Generating Persistent Local Instances of Ontological Mappings |
| US11934441B2 (en) | 2020-04-29 | 2024-03-19 | International Business Machines Corporation | Generative ontology learning and natural language processing with predictive language models |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0108074D0 (en) * | 2001-03-30 | 2001-05-23 | British Telecomm | Database management system |
| US6965900B2 (en) * | 2001-12-19 | 2005-11-15 | X-Labs Holdings, Llc | Method and apparatus for electronically extracting application specific multidimensional information from documents selected from a set of documents electronically extracted from a library of electronically searchable documents |
| US20030172368A1 (en) * | 2001-12-26 | 2003-09-11 | Elizabeth Alumbaugh | System and method for autonomously generating heterogeneous data source interoperability bridges based on semantic modeling derived from self adapting ontology |
| AU2003211000A1 (en) * | 2002-02-12 | 2003-09-04 | Sandpiper Software, Inc. | Ontology frame-based knowledge representation in the unified modeling language (uml) |
| JP2006508434A (ja) | 2002-11-15 | 2006-03-09 | フォン・シュヴェーバー，エリック | 情報サーベイのための方法及び装置 |
| US20060036633A1 (en) * | 2004-08-11 | 2006-02-16 | Oracle International Corporation | System for indexing ontology-based semantic matching operators in a relational database system |
| US20060165040A1 (en) | 2004-11-30 | 2006-07-27 | Rathod Yogesh C | System, method, computer program products, standards, SOA infrastructure, search algorithm and a business method thereof for AI enabled information communication and computation (ICC) framework (NetAlter) operated by NetAlter Operating System (NOS) in terms of NetAlter Service Browser (NSB) to device alternative to internet and enterprise & social communication framework engrossing universally distributed grid supercomputing and peer to peer framework |
| US7996760B2 (en) * | 2004-12-15 | 2011-08-09 | Sap Ag | Acquisition of user data over a network |
| US7734557B2 (en) * | 2005-04-05 | 2010-06-08 | The Board Of Trustees Of Leland Stanford Junior University | Methods, software, and systems for knowledge base coordination |
| JP4859456B2 (ja) | 2005-12-27 | 2012-01-25 | 株式会社日立製作所 | データスキーマのマッピングプログラム及び計算機システム |
| US20070162409A1 (en) | 2006-01-06 | 2007-07-12 | Godden Kurt S | Creation and maintenance of ontologies |
| US20070198448A1 (en) * | 2006-02-21 | 2007-08-23 | International Business Machines Corporation | Scalable ontology reasoning |
| CN101093493B (zh) * | 2006-06-23 | 2011-08-31 | 国际商业机器公司 | 数据库查询语言转换方法、转换装置 |
| CN101145152B (zh) | 2006-09-14 | 2010-08-11 | 国际商业机器公司 | 在特定上下文内自动精细化本体的系统和方法 |
| KR100868331B1 (ko) | 2007-02-23 | 2008-11-11 | 성균관대학교산학협력단 | 상황인식을 위한 온톨로지 시스템과 그 온톨로지 관리 방법및 이를 기록한 기록매체 |
| US7730098B2 (en) * | 2007-03-02 | 2010-06-01 | International Business Machines Corporation | Method for supporting ontology-related semantic queries in DBMSs with XML support |
| US20080228812A1 (en) | 2007-03-15 | 2008-09-18 | Honeywell International Inc. | Method and System for Metamodeling Using Dynamic Ontology Objects |
| CN101286151A (zh) * | 2007-04-13 | 2008-10-15 | 国际商业机器公司 | 建立多维模型和数据仓库模式的映射的方法及相关系统 |
| WO2009032287A1 (en) | 2007-09-07 | 2009-03-12 | Enhanced Medical Decisions, Inc. | Management and processing of information |
-
2009
- 2009-04-30 EP EP09159178A patent/EP2246810A1/en not_active Withdrawn
-
2010
- 2010-04-27 WO PCT/EP2010/055620 patent/WO2010125061A2/en not_active Ceased
- 2010-04-27 PT PT107176158T patent/PT2425383E/pt unknown
- 2010-04-27 EP EP10717615.8A patent/EP2425383B1/en active Active
- 2010-04-27 US US13/266,882 patent/US8849874B2/en active Active
- 2010-04-27 PL PL10717615T patent/PL2425383T3/pl unknown
- 2010-04-27 DK DK10717615.8T patent/DK2425383T3/en active
- 2010-04-27 ES ES10717615.8T patent/ES2553971T3/es active Active
-
2014
- 2014-08-27 US US14/470,433 patent/US9171022B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010125061A3 (en) | 2011-05-19 |
| US8849874B2 (en) | 2014-09-30 |
| PT2425383E (pt) | 2015-12-07 |
| EP2425383B1 (en) | 2015-08-26 |
| US20120117023A1 (en) | 2012-05-10 |
| WO2010125061A2 (en) | 2010-11-04 |
| US9171022B2 (en) | 2015-10-27 |
| PL2425383T3 (pl) | 2016-01-29 |
| EP2425383A2 (en) | 2012-03-07 |
| EP2246810A1 (en) | 2010-11-03 |
| US20150046392A1 (en) | 2015-02-12 |
| DK2425383T3 (en) | 2015-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2553971T3 (es) | Método y dispositivo para la evolución ontológica | |
| Vrgoc et al. | Millenniumdb: A persistent, open-source, graph database | |
| DK2425382T3 (en) | METHOD AND APPARATUS FOR IMPROVED CONSTRUCTION OF AN ONTOLOGY SYSTEM | |
| Freund et al. | A formalization of membrane systems with dynamically evolving structures | |
| Rajlich | Intensions are a key to program comprehension | |
| Wang | Entity grammar systems: a grammatical tool for studying the hierarchal structures of biological systems | |
| ES2389363T3 (es) | Dispositivo de tratamiento de datos con definición formal | |
| El Hamlaoui et al. | A Model-Driven Approach to align Heterogeneous Models of a Complex System. | |
| Astarte et al. | Formal semantics of ALGOL 60: four descriptions in their historical context | |
| Jackson | Software abstractions, revised edition: logic, language, and analysis | |
| Vepštas | Graphs, metagraphs, ram, cpu | |
| Grzelak et al. | Improving Bigraph Rewriting with GrGen. NET to Enable Efficient System Simulation | |
| Sekerinski et al. | Formal Methods | |
| Chen | Neurosymbolic program synthesis for data analytics | |
| Wenneker | BibMix: Enrichment of citation metadata based on integration of bibliographic data | |
| Ahmad | Translating anti-vertex in cypher for graph databases and graph mining systems | |
| Machowski et al. | Preservation of Manual Changes and Provenance for Data Quality using the Nano Version Control Repo | |
| Gorrieri | Language representability of finite place/transition Petri nets | |
| Murakawa et al. | Graphical expression of SQL statements using clamshell diagram | |
| Coughlan | Processing Sequential Files | |
| Sandborg-Petersen | Annotated text databases in the context of the Kaj Munk corpus: One database model, one query language, and several applications | |
| Weber-Jahnke | Modelling of Longitudinal Information Systems with Graph Grammars | |
| Abedrabbo et al. | Neo4j in Action | |
| Haupt | Markush structure reconstruction | |
| Davi et al. | Matching lenses: Alignment and view update |