Modelos de Conocimiento Basados en Ontologías para la ...

More documents

Recommendations

Info

Capítulo 4. Esquema de representación propuesto de PolynomialQuotient que aparezcan en el slot hasPolynomialQuotient de la clase TransferFunctionSystemModel recibirán el nombre de función de transferencia (transfer function en la ontología). El concepto transfer function no tiene existencia como tal, es sólo un nombre que se le da a una instancia de otro concepto (PolynomialQuotient) cuando aparece formando parte de la esencia (cuando aparece en un slot) de un tercero (TransferFunctionSystemModel en este caso). Es por tanto el nombre que recibe una instancia bajo determinadas condiciones, es decir, en un determinado contexto. Una vez descrito el problema de conceptualización hay que tomar la decisión de incorporar el nuevo concepto "función de transferencia" en la ontología como una clase, como un slot o como una instancia. La elección entre una u otra opción no es trivial ni tiene una solución única y óptima. Si se elige conceptualizar el concepto "función de transferencia" como una clase habría que tener una forma de especificar su definición en la forma en la que se ha descrito anteriormente a nivel de clase. Este hecho supone el uso de metaclases, es decir, clases que deberán llevar más información que la que habitualmente las describe con el fin de recoger esa definición. Esto significaría mayor complejidad del formalismo de representación de marcos (aunque es perfectamente posible hacerlo). El uso generalizado de metaclases es habitual en algunas ontologías basadas en marcos, como el modelo fundacional de anatomía FMA (Foundational Model of Anatomy) (Rosse y Mejino, 2003). También hay que tener en cuenta que construir una nueva clase para "función de transferencia" sería poner este concepto al nivel de otros descritos mediante clases, es decir, al mismo nivel que el propio concepto PolynomialQuotient. Lo cierto es que ambos conceptos no son equivalentes sino que, como se ha dicho, "función de transferencia" es un nombre que reciben ciertas instancias de PolynomialQuotient cuando aparecen en la descripción de otro concepto. Si se hiciese una clase, habría instancias exactamente iguales que tendrían clases diferentes ya que cada instancia no puede serlo de dos clases diferentes 93 . Podría hacerse la mezcla de las clases PolynomialQuotient y una clase hipotética TransferFunction creando una clase hija de esas dos (la herencia múltiple sí es un mecanismo habitual en las ontologías basadas en marcos) pero esto se suele hacer cuando ambas clases ofrecen características o propiedades propias a la clase hija y en este caso ya se ha visto que es una 93 En el formalismo de marcos una instancia sólo lo puede pertenecer a una sola clase. En OWL sí se permite que una instancia lo sea de más de una clase. 106
Capítulo 4. Esquema de representación propuesto cuestión de contexto. Por estas razones no parece conveniente poner este concepto a nivel de clase. La solución de conceptualizar "función de transferencia" como un slot sería en la práctica sustituir el slot hasPolynomialQuotient de la clase TransferFuncitonSystemModel por un slot hasTransferFunction. En este caso se perdería la separación entre el lenguaje de control y el de las matemáticas, no habría forma de utilizar el término "función de transferencia" como concepto independiente. La tercera opción, que es la que se ha elegido, es utilizar una instancia. Aparte de la menor adecuación de clase y slot vista anteriormente, la justificación de la decisión se basa en que, de esta manera, se puede utilizar el nivel de clase para describir cómo se definen o calculan los conceptos propios de la ingeniería de control. Con esta aproximación, el nivel de las clases contendrá el esqueleto para especificar el contexto en el que se aplica el concepto de control, mientras que las instancias de estas clases serán los propios conceptos de control en los que se explicitan los diferentes conceptos. TransferFunctionSystemModel hasPolynomialQuotient PolynomialQuotient hasNumerator hasDenominator DescendingPowersOfVariablePolynomialDescription hasDescendingPowersOfVariable transfer function Polynomial hasDescendingPowersOfVariableDescription hasRootsAndGainDescription RootsAndCoeffPolynomialDescription hasLeadingCoefficient hasRoots ComplexNumber RealAndImaginaryPartsDescription hasRealPart hasImaginaryPart RealNumber hasNumericalValue Built-in Float in ontology transfer function hasEntityName hasPath transfer function hasBaseClass hasRealAndImaginaryPartDescription hasModulusAndArgumentDescription ModulusAndArgumentDescription hasModulus hasArgument hasPolynomialQuotient TransferFunctionSystemModel Figura 4.16. Posible conceptualización del concepto transfer function en base a la estructura básica de conceptos. Tomando como ejemplo el concepto "función de transferencia" habría que poder expresar que esta instancia describe a las instancias de PolynomialQuotient 107
Page 1:
Universidad de León Departamento d
Page 5:
Agradecimientos Mi más profundo ag
Page 9 and 10:
Indice Lista de acrónimos y abrevi
Page 11:
Indice 4.5.9 Otras conceptualizacio
Page 14 and 15:
Lista de acrónimos y abreviaturas
Page 17 and 18:
Índice de figuras Figura 3.1 Estru
Page 19:
Prefacio La presente tesis doctoral
Page 22 and 23:
Introducción El problema de la rep
Page 24 and 25:
Capítulo 1. Justificación, objeti
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Capítulo 2. El software en ingenie
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
Page 46 and 47:
Capítulo 3. Representación del co
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77: Capítulo 3. Representación del co
Page 84 and 85: Capítulo 4. Esquema de representac
Page 162 and 163: precondition#1 hasLogicalOperator A
Page 176 and 177:
Capítulo 4. Esquema de representac
Page 178 and 179:
Capítulo 5. Experimentos y resulta
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Page 200 and 201:
Page 202 and 203:
Page 204 and 205:
Page 206 and 207:
Page 209 and 210:
Capítulo 6 Conclusiones finales y
Page 211 and 212:
Capítulo 6. Conclusiones finales y
Page 213 and 214:
Referencias Nota: Todos los enlaces
Page 215 and 216:
Referencias (Bissell, 2004) Bissell
Page 217 and 218:
Referencias knowledge acquisition.
Page 219 and 220:
Referencias OWLED 2006 - OWL: Exper
Page 221 and 222:
Referencias (Genesereth y Nilsson,
Page 223 and 224:
Referencias (Hayes, 1985) Hayes, P.
Page 225 and 226:
Referencias (Kitamura y Mizoguchi,
Page 227 and 228:
Referencias Logics. Stanford, CA, A
Page 229 and 230:
Referencias (Newell, 1982) Newell,
Page 231 and 232:
Referencias (Rector, 2004) Rector,
Page 233 and 234:
Referencias (Speel, 1995) Speel P.-
Page 235 and 236:
Referencias (Varsamidis et. al., 19
Page 237:
Las frases que nunca escribiré, lo
show all

Modelos de Conocimiento Basados en Ontologías para la ...

Create successful ePaper yourself

Delete template?

Save as template?