Tesis Bases de Datos Heterogéneas

TITULO
Consultando Bases de Datos HeterogŽneas Utilizando una Ontolog’a y Funciones de
Similitud.
TESISTA
GutiŽrrez Valenzuela, Mariella Andrea, R.U.T 10.420.482-1
marielag@ucsc.cl
PROFESOR GUêA
Rodr’guez Tastets, Mar’a Andrea, Departamento de Ingenier’a Inform‡tica y Ciencias de la Computaci—n,
Universidad de Concepci—n
RESUMEN
La idea de este proyecto surge de la inquietud de c—mo acceder a bases de datos heterogŽneas a travŽs de una
herramienta computacional que haga transparente para el usuario la problem‡tica del acceso y la
recuperaci—n.
Muchos estudios han analizado las diferentes formas de c—mo recuperar informaci—n desde bases de datos
heterogŽneas, los cuales, en su mayor’a, han presentado propuestas a un nivel conceptual enfatizando el uso
de esquemas compartidos o integrados que son generados manual o semi-autom‡ticamente. A diferencias de
estos trabajos previos, esta Tesis presenta un enfoque que no requiere de un nivel de acuerdo entre los
distintos repositorios que van a compartir sus datos. La soluci—n propuesta se basa en un mŽtodo, que
haciendo uso de una ontolog’a para describir los conceptos asociados a los tŽrminos usados en una consulta,
determina din‡micamente los repositorios y los datos que pueden satisfacen la consulta. Los componentes
fundamentales que conforman la soluci—n son: (1) una ontolog’a del usuario que permite expandir una
consulta, (2) metadatos que describen los datos almacenados en cada repositorio y (3) las funciones de
similitud que comparan conceptos dentro de una ontolog’a y que encuentran entidades similares a estos
conceptos dentro de los repositorios de datos.
Este trabajo se enmarca dentro de un enfoque basado en mediadores. El nivel de mediaci—n est‡ dado por
funciones que permiten traducir la consulta del usuario a entidades definidas en la ontolog’a del usuario y
luego, traducir estas entidades a los diferentes esquemas de bases de datos. No s—lo se ha querido limitar las
consultas a encontrar entidades, se desea llegar a un nivel de detalle que permite expresar consultas con
restricciones basadas en valores de atributos que dichas entidades deben satisfacer. Este trabajo propone una
arquitectura de soluci—n la cual ser‡ evaluada en forma experimental a travŽs de la implementaci—n de una
aplicaci—n Web referida al dominio de informaci—n forestal. La informaci—n forestal aqu’ utilizada
corresponde a los datos alfanumŽricos, dejando para un trabajo futuro las consultas referidas a atributos
geomŽtricos de las entidades.
1
FORMULACION DEL PROYECTO
Los datos se han convertido en un recurso tan importante como las materias primas e insumos para las
empresas e instituciones. No es posible realizar un buen proceso de documentaci—n o toma de decisiones si no
se cuenta con las tecnolog’as inform‡ticas que permitan acceder a numerosas fuentes de informaci—n. El
problema est‡ en que muchas veces lo que necesitamos est‡ en fuentes, formatos y hasta en idiomas distintos
y resulta muy ÒcostosoÓ el recuperarlo para posteriormente realizar el procesamiento. La recuperaci—n de
informaci—n desde bases de datos heterogŽneas ha adquirido aœn mayor relevancia debido al continuo
mejoramiento de la interconexi—n entre sistemas computaciones independientes (Internet) que hacen ahora
posible la reutilizaci—n y compartici—n de datos [1, 2].
Presentaci—n del problema
En el contexto de bases de datos heterogŽneas, se distinguen tres tipos de heterogeneidad: sem‡ntica,
esquem‡tica y sint‡ctica. En general la heterogeneidad sem‡ntica se refiere a las diferencias en la informaci—n
del contexto, la esquem‡tica a diferencias en las abstracciones hechas en cuanto a la definici—n de clases,
atributos y sus relaciones y, la sint‡ctica, se refiere a las diferencias en la representaci—n de los datos. Estos
aspectos tienen directa relaci—n con el proceso de creaci—n de una base de datos [3].
Un repositorio de datos est‡ formado por un conjunto de datos referidos a un Dominio particular o Universo
de Discurso (UOD), almacenados en una determinada estructura. Las bases de datos geogr‡ficas, en
particular, se obtienen de abstracciones del mundo real, existiendo tres niveles de abstracci—n: el sem‡ntico, el
esquem‡tico y el sint‡ctico. Primero, a nivel sem‡ntico lo que se hace es categorizar o caracterizar los
elementos del mundo real de manera de diferenciar aquellos que presentan caracter’sticas similares. Luego, a
nivel esquem‡tico las categor’as, identificadas a nivel sem‡ntico, son llevadas a clases, atributos y relaciones
entre clases, que conforman el esquema de la base de datos. Por œltimo, a nivel sint‡ctico se define la
representaci—n geomŽtrica de los datos, as’ como tambiŽn las relaciones topol—gicas de los objetos espaciales
[3, 4].
Para clarificar el problema a consultar bases de datos heterogŽneas, considere el ejemplo de la Figura 1 con
dos repositorios de datos referidos al ‡mbito forestal usando un esquema relacional: un sistema de Control de
Incendios Forestales (Figura 1a) y un sistema de Manejo Forestal (Figura 1b), es decir, un sistema para el
control de las faenas forestales..
Predio
(1,n)
Plantaci—n
(0,n)
(0,n)
Protecci—
n
tiene
Fundo
(1,n)
Otro
Uso
(1,n)
(1,n)
Rodal
Otro
Uso
(b)
(1,1)
Especie
(a)
Figura 1: Repositorios de datos HeterogŽneos. (a) Control de Incendios Forestales; (b) Manejo Forestal.
El repositorio de datos de Control de Incendios considera un objeto principal o clase llamado predio forestal,
el cual es dividido en tres objetos o subclases: plantaci—n, ‡rea de protecci—n y otro uso. La plantaci—n tiene
un atributo que es la especie plantada que se representa por una cadena de caracteres (string). Por otro lado, el
repositorio de Manejo Forestal tiene un objeto principal que se identifica como fundo, el cual es dividido en
dos subclases u objetos: rodal y otro uso. Del mismo modo, el rodal tiene un atributo que es la especie que
hace referencia a un c—digo identificando una instancia del objeto tipo de especie dentro del repositorio.
En este ejemplo se hacen evidentes dos de los tres tipos de heterogeneidades entre los repositorios de datos. Si
se analiza la sem‡ntica, se puede ver que los objetos que se identifican en estos repositorios de datos son
2
diferentes, da la idea de un lenguaje diferente, sin embargo un predio forestal puede ser equivalente a un
f u n d o y una p la n ta c i— n a un rodal. Luego, si consideramos solucionado el problema sem‡ntico y
efectivamente hablar de predio forestal y fundo es lo mismo, se ve que a nivel esquem‡tico existen tambiŽn
grandes diferencias, la jerarqu’a de clases no es la misma y atributos iguales (especie) tienen dominios de
definici—n distintos, es decir, los elementos que se identifican en uno y otro repositorio de datos son
diferentes. Usando estas dos bases de datos, los usuarios podr’an querer realizar las siguientes preguntas:
•
•
Usuario de la base (a) sobre la base (b): ÀCu‡ntas hect‡reas de plantaci—n de pino existen?
Usuario de la base (b) sobre la base (a): ÀDel total de superficie de fundos con incendios el a–o 2003,
cu‡ntas hect‡reas correspondieron a rodales?
Es evidente que al no existir un mecanismo que permita solucionar los problemas de heterogeneidad
sem‡ntica y esquem‡tica de estas bases de datos, los usuarios no encontrar‡n respuestas acertadas a sus
interrogantes. Esto es, justamente, lo que se quiere evitar al abordar este problema.
Antecedentes y Trabajos Relacionados
Existen muchas investigaciones que han tratado el problema del acceso de informaci—n desde bases de datos
heterogŽneas. En general, estas propuestas han abordado el problema desde dos aspectos: la heterogeneidad
esquem‡tica y la sem‡ntica. Cada uno de los trabajos estudiados propone una forma de soluci—n que tiene un
mayor o menor grado de participaci—n del usuario final.
Las soluciones a nivel esquem‡tico, van desde soluciones donde el usuario debe conocer la estructura y
lenguaje de las bases de datos que quiere acceder, lo que implica un alto grado de conocimiento y
participaci—n de su parte, pasando por aquellas soluciones que proponen la elaboraci—n de esquemas comunes
entre diferentes esquemas de bases de datos fuentes o bien la utilizaci—n de un mediador de contexto para
traducir las consultas del usuario, hasta aquellas soluciones mixtas en las cuales se combinan estructuras de
lenguajes y esquemas comunes [3, 5].
A nivel de manejo de heterogeneidad sem‡ntica, la recuperaci—n basada en ontolog’as, a veces llamada
recuperaci—n de conocimiento, ha sido considerada por muchos autores para abordar este problema. En el
contexto de este trabajo, una ontolog’a es un artefacto de ingenier’a, conformado por un vocabulario
espec’fico utilizado para describir una cierta realidad, m‡s un conjunto de supuestos referentes al significado
de las palabras del vocabulario [6].
Heterogeneidad Esquem‡tica
Mœltiples arquitecturas han sido propuestas que abordan el problema de heterogeneidad esquem‡tica entre
bases de datos [3]. Un resumen de estas alternativas de soluci—n es el siguiente:
3
a) Sin Esquema Compartido ni Mediador de Contexto
USER
TambiŽn conocido como Sistema de Bases de Datos
Mœltiples. En este enfoque, los usuarios formulan las
preguntas utilizando el esquema exportado del proveedor de
la informaci—n. Un esquema exportado es un subconjunto de
una base de datos, que los usuarios desean compartir de
comœn acuerdo. Los usuarios tienen la responsabilidad de
resolver los conflictos entre los esquemas locales y el
exportado [7].
Export Schema
Export Schema
shareable data
(schema 1)
shareable data
(schema 2)
DB1
DB2
Context 1
Context 2
Figura 2: Sin Esquema Compartido ni
Mediador de Contexto.
b) Con Esquema Compartido y sin Mediador de Contexto
USER
En este enfoque, los dise–adores de las bases de datos
tratan de solucionar los conflictos entre todos los
componente, dise–ando un esquema asociado (federated
schema), tambiŽn llamado esquema unificado o global.
Este esquema se mantiene en un servidor (federated
server), el cual contiene un directorio con todas las fuentes
de datos. Los usuarios realizan las consultas bas‡ndose en
el esquema unificado [8].
Federated O. O. Schema
Export Schema
Export Schema
shareable data
(schema 1)
shareable data
(schema 2)
DB1
DB2
Context 1
Context 2
Figura 3: Con Esquema Compartido y sin
Mediador de Contexto.
c) Sin Esquema Compartido y con Mediador de Contexto
En este enfoque, el usuario realiza las consultas en su
propio vocabulario, sin necesidad de identificar los
conflictos. El mediador de contextos (context
mediator) maneja las diferencias entre el contexto del
usuario y el de la fuente de informaci—n.
El mediador compara el contexto del que hace la
pregunta con el contexto del receptor y reformula la
consulta de manera que el receptor la entienda. Esto
requiere que el emisor y el receptor hayan generado un
mapeo entre sus propios contextos y el contexto
mediador [9].
Proxy-context
mediation
USER
Export Schema
Export Schema
shareable data
(schema 1)
shareable data
(schema 2)
DB1
DB2
Context 1
Context 2
Figura 4: Sin Esquema Compartido y con
Mediador de Contexto.
4
d) Con Esquema Compartido y Mediador de Contexto
Este enfoque adopta una combinaci—n del
esquema unificado y el mediador de
contexto para resolver los problemas
esquem‡ticos y sem‡nticos.
Los usuarios pueden realizar sus consultas
en su propio vocabulario, las que luego son
transformadas a un contexto compartido y
luego transferidas hacia el esquema
exportado de la fuente de informaci—n. El
conjunto de datos es recibido
transform‡ndolo en el esquema unificado y
luego al esquema exportado del usuario. El
mediador de contexto es utilizado para
realizar un mapeo entre los esquemas
involucrados [3].
Proxy-context
mediation
Federated O. O. Schema
Context definition
Export Schema
shareable data
(schema 1)
Context definition
Export Schema
USER
shareable data
(schema 2)
DB1
DB2
Context 1
Context 2
Figura 5: Con Esquema Compartido y Mediador de Contexto
Heterogeneidad Sem‡ntica
A nivel de manejo de heterogeneidad sem‡ntica, la recuperaci—n basada en ontolog’as, a veces llamada
recuperaci—n de conocimiento, usa primitivas de una ontolog’a para especificar consultas y descripci—n de
recursos. Estas primitivas con gran contenido sem‡ntico pueden lograr una mejor correspondencia entre la
consulta y los datos almacenados. En los sistemas de informaci—n actuales que se basan en ontolog’as, la
correspondencia sem‡ntica ha significado el acuerdo en el vocabulario usado por varios usuarios. As’,
impl’citamente, se asume que los usuarios comparten una misma conceptualizaci—n, la que corresponde a la
intersecci—n de cada una de las conceptualizaciones individuales [6].
A continuaci—n se presentan sistemas basados en ontolog’as para la recuperaci—n o integraci—n de
informaci—n.
a) OBSERVER
El dise–o de OBSERVER [5, 10-12] refleja la necesidad de crear un sistema que sea altamente independiente
del nœmero de repositorio y ontolog’as y que sea capaz de manejar distintos tipos de heterogeneidades a nivel
estructural, funcional y sem‡ntico.
Cada nodo incluye capacidades de procesamiento de consultas y adicionalmente, repositorios de datos
accesibles por el resto de los nodos a travŽs de ontolog’as que las describen. Para tratar de resolver el
problema del vocabulario, se tiene un repositorio compartido que contiene las relaciones inter-ontol—gicas.
Este repositorio llamado Interontology Relationship Manager (IRM) puede ser visto como un cat‡logo de la
sem‡ntica del sistema. Esta arquitectura se puede dividir en tres funciones: procesamiento de la consulta,
servidor de ontolog’a y el administrador de relaciones entre ontolog’as (IRM) (Figura 6).
5
IRM
Data Repositories
Mappings
Interontologies
Terminological
Relationship
Ontology server
IRM Node
Ontologies
Ontologies
Ontologies
Query processor
User Query
User Node
Component Node
Component Node
Mappings
Ontology server
ooo
Query processor
Mappings
Ontology server
Query processor
Ontologies
Ontologies
Ontologie
Data Repositories
Ontologies
Ontologies
Ontologie
Data Repositories
Figura 6: Arquitectura de OBSERVER.
b) Interoperable Spatial Information System (ISIS)
Otra alternativa de soluci—n lo presenta a travŽs del sistema Interoperable Spatial Information System (ISIS)
[13], basada en la soluci—n din‡mica de conflictos de sem‡ntica usando tŽcnicas de multiagentes. ISIS no se
basa en metodolog’as est‡ticas de integraci—n en las cuales los esquemas exportados son integrados para
resolver conflictos de sem‡ntica, sino que en una soluci—n en la cual los conflictos de sem‡ntica pueden ser
resueltos din‡micamente usando tŽcnicas multiagentes, las cuales dependen de un conjunto de contextos para
llevar a cabo correlaciones sem‡nticas o concordancias entre varios sistemas.
La arquitectura funcional de ISIS consiste de dos niveles principales: wrapper level y cooperation level. El
wrapper level consiste de la informaci—n de los proveedores, la cual puede usar diferentes modelos de datos
espaciales. Cada repositorio est‡ asociado a un wrapper cuya tarea principal es facilitar el acceso externo al
repositorio proveyendo un esquema exportado descrito con AMUN. El cooperation level provee servicios y
funcionalidades para facilitar resoluciones sem‡nticas y el procesamiento de consultas. Estos servicios
involucran los aspectos din‡micos del sistema cooperativo, que incluye el conocer la fuente de informaci—n, la
resoluci—n de conflictos y la ejecuci—n de la consulta.
Los principales componentes de ISIS son una ontolog’a comœn, los esquemas cooperativos y las
trasnformaciones de contexto (Figura 7). Una ontolog’a comœn (common Ontology) es utilizada para capturar
la sem‡ntica de un dominio de aplicaci—n y definir un marco sem‡ntico que entrega descripciones concisas de
la informaci—n sem‡ntica que son independientes de las representaciones sint‡cticas de los datos locales. Los
esquemas cooperativos (cooperative schemas) est‡n compuestos de clases cooperativas que representan una
interpretaci—n de la sem‡ntica local de una clase de mediaci—n, definiendo diferentes facetas o conceptos
ontol—gicos. Finalemente, las transformaciones de contexto (context tranformations) son utilizadas para
relacionar contextos cooperativos (es decir, los objetos ontol—gicos aceptados por un sitio) con los contextos
locales de las fuentes de informaci—n.
6
Common Ontology
Cooperation Level
Mediation Object
Hierarchy
Common Context
Ontological
Commitment
Cooperation Schema
Cooperation Schema
Cooperative Context
Wrapper Level
Context
Transformations
Cooperation Objects
Hierarchy
wrapper schema
wrapper schema
Local Context
Local
Objects
Local GIS 1
Local GIS 2
Figura 7: Arquitectura Funcional de ISIS.
c)
Ontology Driven Geographic Information Systems (ODGIS)
Para el caso de la integraci—n de sistemas de informaci—n, se presenta una soluci—n llamada Ontology Driven
Geographic Information Systems (ODGIS) [14]. La estructura de ODGIS incluye dos aspectos principales: la
generaci—n del conocimiento y el uso del conocimiento. La generaci—n del conocimiento involucra la
especificaci—n de las ontolog’as utilizando un editor de ontolog’as, la generaci—n de nuevas ontolog’as a partir
de las existentes y la traducci—n de ontolog’as en componentes de software. El uso del conocimiento cuenta
con los productos generados en la fase anterior: un conjunto de ontolog’as especificadas en un lenguaje
formal y un conjunto de clases. Las ontolog’as est‡n disponibles para ser usadas por los usuarios finales y
proveen metadata de la informaci—n disponible. Un conjunto de clases que contienen datos y operaciones
constituyen la funcionalidad del sistema. Estas clases son enlazadas a las fuentes de informaci—n geogr‡fica a
travŽs del uso de mediadores.
En Figura 8 se presenta la arquitectura general de ODGIS. El Ontology Server tiene un rol central, pues
provee la conexi—n entre todos los componentes principales. Es tambiŽn responsable de hacer que las
ontolog’as estŽn disponibles para las aplicaciones. La conexi—n con las fuentes de informaci—n es realizada
utilizando mediadores. Las ontolog’as est‡n representadas por dos tipos de estructuras: las especificaciones y
las clases. Las especificaciones son hechas por expertos y almacenadas de acuerdo a sus caracter’sticas
distintivas y a sus interrelaciones sem‡nticas. Las clases son el resultado de la traducci—n de las ontolog’as.
Las fuentes de informaci—n pueden ser cualquier tipo de base de datos geogr‡ficas. El mediador tiene la
funci—n de extraer las piezas de informaci—n necesarias para generar una instancia de una entidad de una
ontolog’a.
Applications
Information
Sources
Mediators
Ontology
Server
Ontologies
Specifications
Classes
Figura 8: Arquitectura b‡sica de un ODGIS.
7
En los diferentes trabajos realizados previamente, se proponen arquitecturas conformadas principalmente por
Esquemas Comunes (Federated Schemas), Mediadores de contexto (context Mediators), u Ontolog’as
(Ontology). En la mayor’a de estas propuestas se supone un cierto nivel de acuerdo entre las distintas bases de
datos de manera de definir un contexto comœn y realizar las consultas sobre los datos. Esta Tesis, por otro
lado, toma como antecedentes las diferentes propuestas de soluci—n al problema de la heterogeneidad
esquem‡tica, para generar un esquema de soluci—n en que no se requiera un nivel de acuerdo entre los
diferentes repositorios de datos. Para ello, se toma como base el trabajo realizado en [15], que define un
mŽtodo de recuperaci—n basado en ontolog’as y funciones de similitud, y lo extiende para incluir no s—lo
consultas basadas en tipos o clases de entidades sino tambiŽn, definidas en tŽrminos de valores de atributos.
Objetivo general
Definir una arquitectura y modelo de recuperaci—n de informaci—n desde bases de datos heterogŽneos que
considere recuperaci—n por tipo de entidad y por valores de atributos.
Objetivos Espec’ficos
1.
Crear un modelo de especificaci—n de consultas donde un usuario no necesite conocer estructuras o
modelos conceptuales de los repositorios de datos heterogŽneos.
2.
Definir un mecanismo de bœsqueda basado en la determinaci—n de similitudes entre entidades y atributos.
3.
Implementar un prototipo del sistema que permita la recuperaci—n de informaci—n desde repositorios de
datos heterogŽneos de forma transparente para el usuario.
Con estos objetivos espec’ficos, esta Tesis no abarca el tratamiento de inconsistencias de los datos que son
recuperados desde bases de datos heterogŽneas, lo cual es dejado como trabajo futuro.
Hip—tesis
A diferencia de una integraci—n de informaci—n desde repositorios de datos heterogŽneos donde las
discrepancias (es decir, el opuesto a la similaridades) deben ser identificadas y resueltas, la recuperaci—n de
informaci—n se basa en la identificaci—n de similaridades entre lo que se tiene almacenado y lo que se busca.
La recuperaci—n de informaci—n puede ser vista, entonces, como un mecanismo de asociaciones (din‡micas o
est‡ticas) entre entidades u ocurrencias similares entre repositorios de datos heterogŽneos.
Al igual que en un modelamiento conceptual, las asociaciones pueden ser jerarquizadas y, siguiendo un
enfoque top-dowm, la correspondencia entre entidades precede a la correspondencia entre ocurrencias o
instancias. A nivel sem‡ntico, la Tesis considera que la correspondencia entre entidades de repositorios de
datos heterogŽneos puede ser establecida al analizar la similitud de sus definiciones en tŽrminos de atributos y
relaciones a vecinos conceptuales. La jerarquizaci—n en la bœsqueda de correspondencia permite no s—lo
disminuir el dominio de bœsqueda sino que tambiŽn, asegurar la convergencia de estos procesos a los
elementos m‡s similares entre s’.
Esta Tesis plantea como propuesta de investigaci—n que el establecimiento de correspondencia entre
instancias de entidades de repositorios de datos heterogŽneos puede ser establecido din‡micamente sin exigir
una asociaci—n fijada a priori entre ellos. Se pretende responder a esta pregunta al definir e implementar un
sistema de consultas a bases de datos heterogŽneas que permita comparar la recuperaci—n autom‡tica de los
datos con una recuperaci—n guiada por el usuario.
8
METODOLOGIA Y PLAN DE TRABAJO
La soluci—n propuesta se basa en un mŽtodo de recuperaci—n basado en ontolog’as. En este contexto, una
Ontolog’a es un artefacto de ingenier’a conformado por un vocabulario espec’fico utilizado para describir una
cierta realidad, m‡s un conjunto de supuestos referentes al significado de las palabras del vocabulario [6]. Los
componentes fundamentales que conforman esta soluci—n son una ontolog’a que permite expandir una
consulta del usuario, los metadatos que describen el contenido de las bases de datos y las funciones de
similitud que comparan conceptos dentro de una ontolog’a y encuentran entidades similares a estos conceptos
dentro de los repositorios de datos.
Considerando la ontolog’a como componente principal, se espera abarcar dos de las tres componentes sem‡ntica y esquem‡tica - de las bases de datos heterogŽneas. Para ello, se propone agrupar los distintos
repositorios de datos en ÒDominios de Aplicaci—n Tem‡ticosÓ, considerando que en repositorios referidos a
un mismo tema, la heterogeneidad sem‡ntica y esquem‡tica ser‡ menor que en aquellos de contextos
diferentes. Si un usuario desea consultar datos desde diferentes repositorios de datos, es previsible que Žstos
tengan al menos en comœn el contexto, de manera tal de que las respuestas encontradas sean m‡s acertadas.
Por ejemplo, no se espera que un usuario de datos forestales realice una pregunta del ‡mbito forestal sobre
bases de datos forestales, agr’colas y urbanos. Lo m‡s probable es que s—lo encuentre respuestas posibles
dentro del repositorio de datos forestal. Sin embargo, un usuario del ‡rea de transporte quiz‡ s’ encuentre
informaci—n relevante, relativa a rutas de transporte tanto urbano como rural, puesto que este tipo de
informaci—n es considerada tanto en bases de datos urbanas, como forestales y agr’colas. En este œltimo caso,
el contexto estar’a dado por el tema transporte.
En este proyecto se propone realizar esta definici—n del contexto del dominio que un usuario desea consultar a
travŽs de una Ontolog’a (user ontology). Esta ontolog’a incluye los tŽrminos y sin—nimos de los tŽrminos, las
interrelaciones sem‡nticas entre los tŽrminos, como tambiŽn los atributos y sin—nimos de los atributos, que
los caracterizan. Al incorporar tŽrminos y atributos con sus sin—nimos se trata de disminuir los problemas que
se presentan con el uso de tŽrminos que son sin—nimos o polysŽmicos.
La Figura 9 presenta la arquitectura propuesta. En esta arquitectura se propone una Interfaz de Consulta de
Usuario (UI) [16], la cual le permite al usuario ingresar uno o m‡s conceptos para conformar su consulta y
entrega a Žste los resultados parciales y finales de su procesamiento. El componente principal de esta
arquitectura es el Procesamiento de la Consulta (Query Processing), que es el que realiza el procesamiento
completo de la consulta y para lo cual se compone de tres subprocesos: pre-procesamiento de la consulta
(query pre-processing) (es decir, validaci—n, expansi—n, filtro), bœsqueda (query search in DB1..DBn),
recuperaci—n (data retrieval from DB1..DBn).
USER
UI
Query Pre-Processing
User
Ontology
Query Search
Schema
DB1..n
Data Retrieval
Query Processing
DB1..n
Figura 9: Arquitectura de la Soluci—n.
9
En el pre-proceasamiento de la consulta (query pre-processing) los conceptos que ingresa el usuario son
validados y expandidos en funci—n de las entidades de la Ontolog’a del Usuario (User Ontology). Adem‡s, es
posible especificar m‡s detalladamente la consulta aplicando uno o m‡s filtros a cada una de las entidades, lo
que se traduce en la incorporaci—n de atributos y valores de atributos a la consulta. Luego, en la bœsqueda
(query search) las definiciones de estas entidades son ejecutadas sobre cada base de datos a travŽs de la
comparaci—n entre las definiciones ontol—gicas y las definiciones obtenidas de los metadatos que describen el
contenido de los repositorios de datos (Scheme DB1É.Scheme DBn). Este proceso genera consultas en los
tŽrminos utilizados por cada uno de los repositorios de datos, las cuales son ordenadas de acuerdo a su grado
de similitud con respecto de la consulta original. Finalmente, si el usuario desea efectivamente recuperar las
instancias asociadas a una consulta, debe seleccionarla con lo cual se ejecutar‡ la funci—n de recuperaci—n y
despliegue de resultados (Data Retrieval).
La interacci—n entre los distintos elementos de la arquitectura est‡ dada por las funciones mediadoras (Figura
10). Una descripci—n de estas funciones es la siguiente:
•
Validar: Proporciona al usuario la posibilidad de incorporar conceptos a la consulta. Se valida que los
conceptos que ingresa el usuario pertenezcan a la Ontolog’a.
•
Expandir: Proporciona al usuario la posibilidad de ÒexpandirÓ un tŽrmino v‡lido usando la ontolog’a, es
decir, se generar‡ una lista de conceptos v‡lidos asociados al concepto expandido.
•
Filtrar: Permite al usuario desplegar la lista de atributos pertenecientes a un concepto ya validado.
Adem‡s permite que el usuario seleccione los atributos que incorporar‡ en su consulta y los operadores
de comparaci—n y valores que conformar‡n los criterios de bœsqueda.
•
Buscar: Proporciona al usuario la opci—n de gatillar la bœsqueda ingresada en tŽrminos de la ontolog’a a
tŽrminos de cada uno de los esquemas. Entregar‡ al usuario una lista de repositorios en donde se
encuentra lo que est‡ buscando, adem‡s de un porcentaje asociado a la similitud de lo buscado con lo
encontrado. Asociado a cada resultado se encuentra una consulta en los tŽrminos del repositorio
correspondiente.
•
Recuperar: Proporciona al usuario la posibilidad de ÒejecutarÓ los resultados de la bœsqueda en un
repositorio espec’fico. Para ello ejecuta en el repositorio remoto la consulta del usuario y despliega en la
interfaz del usuario (UI) las instancias que la satisfacen.
10
Query Pre-Processing
Concepto
User
Validar
Concepto
Validado
Entidades,
atributos y
valores
Conceptos
Relacionados
Expandir
Filtrar
User
Query
Search
User Ontology
Query Search
User
Entidades,
atributos y
valores
Buscar
Scheme
DB1
User
Consulta en
tŽrminos de
DB1..n
Scheme
DBn
DB1..n Result
Recuperar
(From DB1..n )
Query
Search
DB1
User
Data
Retrieve
(Query to DB1..n )
Query PreProcessing
Data Retrieval
Consultas en
tŽrminos de
DB1..n
Ordenadas
User
DBn
Figura 10: Funciones Mediadoras de la Arquitectura de Soluci—n.
En este trabajo no existe una correspondencia establecida entre entidades de un repositorio de datos y una
ontolog’a. Este proceso de establecer asociaciones es dado por medio de funciones de similitud. Las funciones
de similitud son utilizadas en dos de las funciones mediadoras. Primero en la funci—n expandir que permite
encontrar entidades de la ontolog’a con algœn grado de similitud a la entidad o concepto que el usuario desea
consultar. Esta expansi—n ampl’a las posibilidades de encontrar entidades similares a las solicitadas por un
usuario flexibilizando la manera en que los usuarios deben especificar una consulta. Esto se hace m‡s
importante en ambientes heterogŽneos donde es dif’cil que un usuario pueda a priori saber la forma en que
debe especificar una entidad. Luego, cuando la consulta del usuario ya ha sido conformada en base a la
ontolog’a, la funci—n buscar utiliza funciones de similitud para realizar una asociaci—n entre las entidades del
repositorio de datos y la ontolog’a.
La funci—n de similaridad ser‡ definida en base a los resultados previos que comparan conceptos espaciales
[17]. Esta Tesis extiende y complementa el trabajo previo [15] al no se considera la definici—n de ontolog’as
para cada una de los repositorios de datos, sino una œnica ontolog’a del usuario como base de especificaci—n
de consultas y el uso de metadata o esquemas que describan el contenido de los repositorios de datos. De esta
manera, se relaja el requerimiento de tener una completa descripci—n conceptual de las entidades almacenadas
en cada uno de los repositorios, la cual es el caso ideal, pero que en la pr‡ctica es menos probable. Como
consecuencia de esto, las funciones de similitud deben ser ajustadas para considerar s—lo la definici—n parcial
de entidades en los metadata.
11
Para la definici—n de entidades espaciales dentro de la ontolog’a se ha utilizado como base la estructura
propuesta en [18], de la cual se ha considerado s—lo un subconjunto de los elementos definidos. Las entidades
son referenciadas por palabras o un conjunto de sin—nimos, los cuales son interrelacionados por sus
hip—nimos o relaciones is_a y por sus mer—nimos o relaciones part_whole. De las relaciones part_whole se
desprenden dos relaciones, part_of y whole_of, para distinguir cuando una entidad es parte de otra (ej. un
rodal es parte de un fundo) o cuando es un todo (ej. un fundo es un conjunto de usos del suelo). Adem‡s, en
esta definici—n de entidad se incorporan caracter’sticas distintivas definidas por atributos. A diferencia de la
ontolog’a usada en [18], este trabajo no ha considerado en la definici—n de entidad ni las funciones (es decir,
que hace o se hace con la entidad) ni las partes (es decir, las partes estructurales de una entidad), debido a que
estos elementos no pueden ser mapeados directamente a componentes de una base de datos real, de la cual
usualmente no se tiene un modelo conceptual. Por otro lado, se ha agregado a la definici—n de los atributos
un nivel de detalle mayor. Adem‡s de considerar el nombre de un atributo, se ha incorporado su tipo y unidad
de medida, lo que permitir‡ en la etapa de bœsqueda y recuperaci—n de informaci—n conformar consultas sobre
los repositorios, que permitan extraer instancias de las bases de datos m‡s espec’ficas (ej. buscar todos los
rodales cuya especie = "pino").
Para la especificaci—n de la ontolog’a propuesta se ha utilizado el lenguaje OWL [19, 20, 21], por ser un
est‡ndar de definici—n de ontolog’as en la Web Sem‡ntica [22-24] desarrollado por el Web Ontology
Working Group de la Organizaci—n W3C1. El lenguaje OWL nace del lenguaje DAML+OIL creado por un
grupo de investigadores Americanos y Europeos que combinan sus propuestas DAML_ONT y OIL
respectivamente. Adem‡s de ser un lenguaje est‡ndar, OWL tiene la ventaja de superar algunas de las
limitaciones de sus lenguajes antecesores, como el RDF y RDFS, en los cuales no se pod’a especificar
restricciones de cardinalidad, combinaciones booleanas de clases, disjoin de clases y algunas caracter’sticas
de las propiedades (transitividad, unicidad, entre otras) [19]. En Anexo 1 se presenta una definici—n gr‡fica
de la ontolog’a utilizando el modelo de grafos RDF Graph Model [19] y en Anexo 2 la especificaci—n en
OWL.
Para la evaluaci—n formal de la soluci—n propuesta, se propone la implementaci—n de una aplicaci—n Web
referida al dominio de informaci—n Forestal [16], para ello se requiere de la definici—n ontol—gica de este
dominio y de al menos dos repositorios de datos experimentales. En la fase de prueba de esta aplicaci—n se
deber‡ poder determinar con quŽ precisi—n se est‡n recuperando los datos, es decir, cu‡nta de la informaci—n
relevante es efectivamente recuperada. Se propone la confecci—n de un conjunto de consultas de prueba, en
distintos niveles de complejidad, de manera de ejecutar cada una de estas consultas directamente en los
repositorios de datos experimentales, previa traducci—n de la consulta al lenguaje espec’fico de cada uno. Esto
nos dar‡ como resultado un conjunto de soluci—n exacto para cada consulta. Luego, se propone ejecutar cada
una de las consultas, expresadas en tŽrminos de la ontolog’a, a travŽs de la aplicaci—n Web, para as’ obtener
conjuntos de soluci—n que deber‡n ser comparados con la soluci—n exacta al problema.
Un resumen de la metodolog’a propuesta es la siguiente:
1.
2.
3.
4.
5.
6.
7.
8.
9.
1
Realizar un Estado del Arte de las ‡reas de acceso y recuperaci—n de datos desde Repositorios de Datos
HeterogŽneos.
Dise–ar y Definir formalmente los componentes de la Arquitectura de soluci—n del problema
Dise–ar e implementar una Ontolog’a de prueba referida al dominio Forestal.
Analizar y modificar la funci—n de similitud propuesta en [17] para extenderla al nivel de instancias.
Dise–ar e implementar las funciones Mediadoras de la Arquitectura de soluci—n.
Implementaci—n y prueba del prototipo de soluci—n propuesta.
Definir e implementar un modelo de recuperaci—n que permita comparar la recuperaci—n autom‡tica de
los datos con una recuperaci—n guiada por el usuario.
Evaluaci—n experimental del prototipo de soluci—n propuesta
Conclusiones y discusiones futuras
http://www.w3.org/2001/sw/WebOnt/
12
PLAN DE TRABAJO
1. Recopilaci—n bibliogr‡fica
2. Dise–o de los componentes de la Arquitectura
3. Dise–o e implementaci—n de la Ontolog’a de prueba
4. Implementaci—n de las funciones mediadoras de la Arquitectura
5. Definir e implementar un modelo de recuperaci—n
6. Evaluaci—n experimental de los resultados
7. Documentaci—n
Agosto
Actividad Junio
Julio
Agosto Sep
Oct
Nov
1.
2.
3.
4.
5.
6.
7.
Dic
Enero
RECURSOS
Para el desarrollo de este proyecto de Tesis se cuenta con los siguientes recursos:
1. Un Servidor (S.O. Linux) con motor de bases de datos Oracle v9i.
2. Dos repositorios de bases de datos espaciales del ‡mbito Forestal, proporcionadas por las empresas
Forestal B’o B’o S.A. y Forestal Mininco S.A.
Se piensa que estos recursos son suficientes para el desarrollo del proyecto puesto que para la implementaci—n
del prototipo al menos se requieren dos bases de datos heterogŽneas. El que ellas se encuentren f’sicamente en
el mismo equipo (servidor), no invalida las pruebas puesto que el usuario podr‡ realizar las consultas a los
datos desde cualquier computador, a travŽs de Internet, s—lo teniendo una cuenta de usuario y password de
acceso al sistema, siendo transparente el lugar f’sico en donde se encuentren los datos.
TRABAJO ADELANTADO
Un adelanto a este proyecto lo constituye la Memoria de T’tulo "Interfaz de Consultas a Bases de Datos
HeterogŽneas" [19]. Este trabajo tuvo como objetivo general el crear la interfaz Web del prototipo que se
pretende implementar en esta Tesis. En esta Memoria de T’tulo ya se consideran la Arquitectura de soluci—n
propuesta en este proyecto, as’ como tambiŽn la estructura de definici—n de la Ontolog’a y funciones
mediadoras del sistema. Espec’ficamente, lo que se presenta en esta memoria de t’tulo, es la componente UI
de la Arquitectura de soluci—n presentada (Figura 9).
13
BIBLIOGRAFIA
[1]
Meller, P.: Distintas visiones sobre Tecnolog’as de Informaci—n (TI) e Internet en Chile. Revista
Perspectivas (Departamento de Ingenier’a Industrial, Universidad de Chile), vol. 5, N¼ 2, 2002, pp. 131142.
[2]
Sheth, A.: Changing Focus on Interoperability in Information Systems: From System, Syntax, Structure
to Semantics. In: M. Goodchild, M. Egenhofer, R. Fegeas, y C. Kottman (eds.), Interoperating
Geographic Information Systems. 1999, pp. 5-30, Kluwer Academic Publishers, Norwell, MA.
[3]
Bishr, Y.: Semantic Aspects of Interoperable GIS. Ph.D. Thesis, Wageningen Agricultural University
and ITC, The Netherlands, 1997.
[4]
De Miguel, A., Piattini, M., Marcos, E.Ê: Dise–o de Bases de Datos Relacionales. ALFAOMEGA
GRUPO EDITOR S.A. DE C. V., 2000.
[5]
Mena, E., Illarramendi, A.: Ontology-Based Query Processing for Global Informaci—n Systems. Kluwer
Academic Publishers, Norwell, Massachusetts, USA, 2001.
[6]
Guarino, N.: Semantic Matching: Formal Ontological Distinctions for Information Organization
Extraction, and Integration. M. Pazienza (ed.), Information Extraction: A Multidisciplinary Approach
to an Engineering Information Technology, Francasi, Italy, Springer Verlag, 1997, pp. 139-170.
[7]
March, T.S.: ACM Computer Surveys, Special Issue on Heterogeneous Databases.Vol 22, N¼ 3,
September 1990. ACM Press.
[8]
Landers, T., Rosenberg, R.: An Overview of Multidatabase. Proceedings of the Ò2nd International
Symposium for Distributed Databases, 1992, pp. 153-183.
[9]
Collet, C., Huhns, M.N., Shen, W. M.: Resorce Integration Using a Large Knowledge Base in Carnot.
IEEE Computer, Vol. 24 N¼ 12, December 1991.
[10] Mena, E., Kashyap, V., Sheth, A.: OBSERVER: An Approach for Query Processing in Global
Information Systems Based on Interoperation Across Pre-Existing Ontologies. International Conference
on Cooperative Information Systems (CoopIS'96), Brussel, Belgium,pp. 14-25, IEEE Computer Society
Press, 1996.
[11] Mena, E., Illarramendi, A., Kashyap, V., Sheth, A.: OBSERVER: An Approach for Query Processing In
Global Information Systems Based on Interoperation across Pre-existing Ontologies. PhD Thesis,
Universidad de Zaragoza, Espa–a. 1998.
[12] Mena, E., Illarramendi, A., Kashyap, V., Sheth, A.: OBSERVER: An Approach for Query Processing In
Global Information Systems Based on Interoperation across Pre-existing Ontologies. Distributed and
Parallel Databases 8, 2000, 223-271
[13] Lecrercq, E., Benslimane, D., YŽtongnon, K.: Semantic Mediation for Cooperative Spatial Information
Systems: The AMUN Data Model, 1998.
[14] Fonseca, F., Egenhofer, M., Agouris, P., Camara,G.: Using Ontologies for Integrated Geographic
Information Systems Transaction in GIS 6(3), 2002.
[15] Rodr’guez, A., Varas, M.: A Knowledge-Based Approach to Querying Heterogeneous Databases. M.
Hacid, Z. R‡s, D. Zighed and Y. Kodratoff (eds.), Methodologies for Intelligent Systems 2002, Lyon,
France.
14
[16] Saavedra, R.: Interfaz de Consultas a Bases de Datos HeterogŽneas. Informe de Memoria de T’tulo Para
optar al T’tulo de Ingeniero Civil Inform‡tico. Departamento de Ingenier’a Inform‡tica y Ciencias de la
Computaci—n, Universidad de Concepci—n. Chile. 2003.
[17] Rodr’guez, M., Egenhofer, M.: Comparing Geospatial Entity Classes: An Asymmetric and ContextDependent Similarity Measure. International Journal of Geographic Information Science. (in press)
[18] Rodr’guez, A, Egenhofer, M. : Determining Semantic Similarity Among Entity Classes from different
Ontologies, IEEE Transactions on Knowledge and Data Engineering. 15(2): 442-456, 2003.
[19] Antoniou, G., Van Harmelen, F.: Web Ontology Language: OWL. Working Draft, 2002.
[20] Dean, M. et al: OWL Web Ontology Language 1.0 Reference. W3C Working Draft, 29 July 2002.
[21] Smith, M. et al: OWL Web Ontology Language 1.0 Guide. W3C Working Draft, 04 November 2002.
[22] Berners-Lee, Hendle, J., Lassila: The Semantic Web, Scientific American 184(4): 34-43, 2001.
[23] Fensel, D., Musen, M: The Semantic Web: A New Brain for Humanity, IEEE Intelligent Systems
16(1):24-25, 2001.
[24] Horrocks, I., Patel-Schneider, P.: Three Theses of Representation in The Semantic Web. Proceeding of
the Twelfth International Conference on World Wide Web. Budapest, Hungary, 2003, pp. 39-47.
15
ANEXO 1: Ontolog’a en el modelo de grafo RDF.
is_a
part_of
whole_of
Entity_class
xsd;nonNegativeInteger
entity_id
has_Attributes
entity_description
attribute_id
has_syns_entity_name
attribute_unit
Xsd;nonNegative
Integer
xsd;nonNegativeInteger
Xsd;string
syns_entity_name
Attribute_class
has_syns_entity_name
entity_name
syns_attribute_
name
has_type
attribute_name
Xsd;string
Xsd;string
Attribute_type
One_of
• Caracter
• Numerico
• Fecha
16
ANEXO 2: Ontolog’a en OWL.
<owl:Class rdf:ID=ÓEntity_classÓ>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#entity_id"/>
<owl:Cardinality>1</owl:Cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#has_syns_entity_name"/>
<owl:Cardinality>1</owl:Cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#entity_description"/>
<owl:Cardinality>1</owl:Cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#has_Attributes"/>
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#is_a"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#part_of"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#whole_of"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID=Óis_aÓ/>
<rdfs:domain rdf:resourse=Ó#Entity_classÓ/>
<rdfs:range rdf:resourse=Ó#Entity_classÓ/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=Ópart_ofÓ/>
<rdfs:domain rdf:resourse=Ó#Entity_classÓ/>
17
<rdfs:range rdf:resourse=Ó#Entity_classÓ/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=Ówhole_ofÓ/>
<rdfs:domain rdf:resourse=Ó#Entity_classÓ/>
<rdfs:range rdf:resourse=Ó#Entity_classÓ/>
<owl:inverseOf rdf:resourse=Ó#part_ofÓ/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=Óhas_AttributesÓ/>
<rdfs:domain rdf:resourse=Ó#Entity_classÓ/>
<rdfs:range rdf:resourse=Ó#Attribute_classÓ/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID=Óentity_idÓ>
<rdfs:domain rdf:resource=Ó#Entity_classÓ/>
<rdfs:range rdf:resource=Ó&xsd;nonNegativeIntegerÓ/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID=Óentity_descriptionÓ>
<rdfs:domain rdf:resource=Ó#Entity_classÓ/>
<rdfs:range rdf:resource=Ó&xsd;stringÓ/>
</owl:DatatypeProperty>
<owl:Class rdf:ID=Ósyns_entity_nameÓ>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#entity_name"/>
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl_class>
<owl:DatatypeProperty rdf:ID=Óentity_nameÓ>
<rdfs:domain rdf:resource=Ó#syns_entity_nameÓ/>
<rdfs:range rdf:resource=Ó&xsd;stringÓ/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID="has_syns_entity_name">
<rdfs:domain rdf:resource="#Entity_class"/>
<rdfs:range rdf:resource="#syns_entity_name"/>
</owl:ObjectProperty>
<owl:Class rdf:ID="Attribute_class">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#attribute_id"/>
<owl:maxCardinality>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#attribute_type"/>
<owl:maxCardinality>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
18
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#attribute_unit"/>
<owl:maxCardinality>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#has_syns_attribute_name"/>
<owl:Cardinality>1</owl:Cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl_class>
<owl:DatatypeProperty rdf:ID=Óattribute_idÓ>
<rdfs:domain rdf:resource=Ó#Attribute_classÓ/>
<rdfs:range rdf:resource=Ó&xsd;integerÓ/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID=Óattribute_unitÓ>
<rdfs:domain rdf:resource=Ó#Attribute_classÓ/>
<rdfs:range rdf:resource=Ó&xsd;integerÓ/>
</owl:DatatypeProperty>
<owl:Class rdf:ID="attribute_type">
<owl:oneOf rdf:parseType="Collection">
< attribute_type rdf:about="Caracter"/>
< attribute_type rdf:about="Numerico"/>
< attribute_type rdf:about="Fecha"/>
</owl:oneOf>
</owl:Class>
<owl:ObjectProperty rdf:ID="has_type">
<rdfs:domain rdf:resource="#Attribute_class"/>
<rdfs:range rdf:resource="#attribute_type"/>
</owl:ObjectProperty>
<owl:Class rdf:ID=Ósyns_attribute_nameÓ>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#attribute_name"/>
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl_class>
<owl:DatatypeProperty rdf:ID=Óattribute_nameÓ>
<rdfs:domain rdf:resource=Ó#syns_attribute_nameÓ/>
<rdfs:range rdf:resource=Ó&xsd;stringÓ/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID="has_syns_attribute_name">
<rdfs:domain rdf:resource="#Attribute_class"/>
<rdfs:range rdf:resource="#syns_attribute_name"/>
</owl:ObjectProperty>
19