Modelos de Conocimiento Basados en Ontologías para la ...
Modelos de Conocimiento Basados en Ontologías para la ... Modelos de Conocimiento Basados en Ontologías para la ...
Capítulo 4. Esquema de representación propuesto El lugar de las raíces se ha tratado como una entidad especial, como una entidad calculada externamente y no definida (caso del resto de entidades). La clase correspondiente a este concepto es NamedCalculatedEntity (es una subclase de NamedEntity) y tiene una estructura similar a la descrita para las características calculadas, es decir, se explicita la función externa a llamar, los parámetros a pasarle y el tipo de datos de retorno. 4.5.9 Otras conceptualizaciones Además de las estructuras de conocimiento presentadas hasta el momento existen otras que complementan a éstas y que están dedicadas a diferentes cometidos. Las más relevantes se presentan a continuación. 4.5.9.1 Expresiones de entidades y características En el método del lugar de las raíces toda entidad que exista se obtendrá, en último término, de un modelo en función de transferencia. Sin embargo, puede existir gran complejidad en la composición de estas entidades cuando aparecen en las expresiones del lenguaje de control. También, cualquier característica se dirá de alguna entidad que, en último término, esté referida a un modelo en función de transferencia. A modo de ejemplo, se puede hacer referencia a la siguiente expresión: 148 “el grado del denominador de la función de transferencia de la planta” En esta expresión entran en juego una característica y una expresión de entidades en las que una entidad se dice de otra entidad que, en último término, se dice de un modelo en función de transferencia. Así, se tiene: • La característica “grado” que se dice de la entidad “denominador de la función de transferencia de la planta”. • La entidad “denominador” que se dice de la entidad “función de transferencia de la planta”. • La entidad “función de transferencia” que se dice de “la planta” (y que en último término, haciendo uso del mapeo, hará referencia a un modelo en función de transferencia (instancia de TransferFunctionSysteModel). Para reflejar estas expresiones se utilizan diferentes conceptos en la ontología. En concreto, para crear expresiones de entidades que se dicen sobre otras entidades se tienen la clase NamedEntityOfSomething que tiene, como subclases:
Capítulo 4. Esquema de representación propuesto • Clase NamedEntityOfANamedEntity, que se utiliza para aplicar una entidad a otras previamente existentes. En esta clase hay un slot para la entidad que se dice de otra y para la entidad de la que se dice algo que, a su vez, puede ser una instancia de esta misma clase, permitiendo así anidamientos de expresiones de este tipo. • Clase NamedEntityOfAGivenSystem, que se utiliza para aplicar una entidad o una expresión compleja de entidades definida como instancia de la clase mencionada anteriormente, a una instancia de bloque canónico (clase CanonicalBlockDiagramComponent ó clase CalculatedCanonicalBlock). Existe otra clase, denominada QuantitativeCharacteristicOfSomething, que recoge las clases dedicadas a expresar características de sistemas, de entidades, y de entidades aplicadas a sistemas. Estas clases son, respectivamente: • Clase QuantitativeCharacteristicOfAGivenSystem. Por ejemplo: type of (plant) • Clase QuantitativeCharacteristicOfANamedEntity. Por ejemplo: degree of (Denominator) • Clase QuantitativeCharacteristicOfANamedEntityOfAGivenSy stem Por ejemplo, la expresión total mencionada al comienzo del apartado: degree of (Denominator of (transfer function of (plant))) 4.5.9.2 Requerimientos de diseño La conceptualización de los requerimientos de diseño en la ontología se utilizará en la parte dinámica de la misma. El uso actual de la misma consiste en su representación gráfica como área de diseño (en el caso de las especificaciones de régimen transitorio). Para representar el conjunto de requerimientos de diseño se ha utilizado la clase DesignObjective, que tiene un slot múltiple en el que se representan los diferentes requerimientos de diseño. Estos requerimientos serán instancias de la clase FrequencyDomainDesignRequirement que, a su vez, estará formada por tres slots: uno para recoger la característica sobre la que se establece el requerimiento, otro para establecer la cláusula de comparación y otro más para recoger el valor deseado para ese requerimiento de diseño. 149
- Page 118 and 119: Capítulo 4. Esquema de representac
- Page 120 and 121: Capítulo 4. Esquema de representac
- Page 122 and 123: Capítulo 4. Esquema de representac
- Page 124 and 125: Capítulo 4. Esquema de representac
- Page 126 and 127: Capítulo 4. Esquema de representac
- Page 128 and 129: Capítulo 4. Esquema de representac
- Page 130 and 131: Capítulo 4. Esquema de representac
- Page 132 and 133: Capítulo 4. Esquema de representac
- Page 134 and 135: Capítulo 4. Esquema de representac
- Page 136 and 137: Capítulo 4. Esquema de representac
- Page 138 and 139: Capítulo 4. Esquema de representac
- Page 140 and 141: Capítulo 4. Esquema de representac
- Page 142 and 143: Capítulo 4. Esquema de representac
- Page 144 and 145: Capítulo 4. Esquema de representac
- Page 146 and 147: Capítulo 4. Esquema de representac
- Page 148 and 149: Capítulo 4. Esquema de representac
- Page 150 and 151: Capítulo 4. Esquema de representac
- Page 152 and 153: Capítulo 4. Esquema de representac
- Page 154 and 155: Capítulo 4. Esquema de representac
- Page 156 and 157: Capítulo 4. Esquema de representac
- Page 158 and 159: Capítulo 4. Esquema de representac
- Page 160 and 161: Capítulo 4. Esquema de representac
- Page 162 and 163: precondition#1 hasLogicalOperator A
- Page 164 and 165: Capítulo 4. Esquema de representac
- Page 166 and 167: Capítulo 4. Esquema de representac
- Page 170 and 171: Capítulo 4. Esquema de representac
- Page 172 and 173: Capítulo 4. Esquema de representac
- Page 174 and 175: Capítulo 4. Esquema de representac
- Page 176 and 177: Capítulo 4. Esquema de representac
- Page 178 and 179: Capítulo 5. Experimentos y resulta
- Page 180 and 181: Capítulo 5. Experimentos y resulta
- Page 182 and 183: Capítulo 5. Experimentos y resulta
- Page 184 and 185: Capítulo 5. Experimentos y resulta
- Page 186 and 187: Capítulo 5. Experimentos y resulta
- Page 188 and 189: Capítulo 5. Experimentos y resulta
- Page 190 and 191: Capítulo 5. Experimentos y resulta
- Page 192 and 193: Capítulo 5. Experimentos y resulta
- Page 194 and 195: Capítulo 5. Experimentos y resulta
- Page 196 and 197: Capítulo 5. Experimentos y resulta
- Page 198 and 199: Capítulo 5. Experimentos y resulta
- Page 200 and 201: Capítulo 5. Experimentos y resulta
- Page 202 and 203: Capítulo 5. Experimentos y resulta
- Page 204 and 205: Capítulo 5. Experimentos y resulta
- Page 206 and 207: Capítulo 5. Experimentos y resulta
- 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.
Capítulo 4. Esquema <strong>de</strong> repres<strong>en</strong>tación propuesto<br />
• C<strong>la</strong>se NamedEntityOfANamedEntity, que se utiliza <strong>para</strong> aplicar<br />
una <strong>en</strong>tidad a otras previam<strong>en</strong>te exist<strong>en</strong>tes. En esta c<strong>la</strong>se hay un slot <strong>para</strong><br />
<strong>la</strong> <strong>en</strong>tidad que se dice <strong>de</strong> otra y <strong>para</strong> <strong>la</strong> <strong>en</strong>tidad <strong>de</strong> <strong>la</strong> que se dice algo que,<br />
a su vez, pue<strong>de</strong> ser una instancia <strong>de</strong> esta misma c<strong>la</strong>se, permiti<strong>en</strong>do así<br />
anidami<strong>en</strong>tos <strong>de</strong> expresiones <strong>de</strong> este tipo.<br />
• C<strong>la</strong>se NamedEntityOfAGiv<strong>en</strong>System, que se utiliza <strong>para</strong> aplicar<br />
una <strong>en</strong>tidad o una expresión compleja <strong>de</strong> <strong>en</strong>tida<strong>de</strong>s <strong>de</strong>finida como<br />
instancia <strong>de</strong> <strong>la</strong> c<strong>la</strong>se m<strong>en</strong>cionada anteriorm<strong>en</strong>te, a una instancia <strong>de</strong> bloque<br />
canónico (c<strong>la</strong>se CanonicalBlockDiagramCompon<strong>en</strong>t ó c<strong>la</strong>se<br />
Calcu<strong>la</strong>tedCanonicalBlock).<br />
Existe otra c<strong>la</strong>se, <strong>de</strong>nominada<br />
QuantitativeCharacteristicOfSomething, que recoge <strong>la</strong>s c<strong>la</strong>ses<br />
<strong>de</strong>dicadas a expresar características <strong>de</strong> sistemas, <strong>de</strong> <strong>en</strong>tida<strong>de</strong>s, y <strong>de</strong> <strong>en</strong>tida<strong>de</strong>s<br />
aplicadas a sistemas. Estas c<strong>la</strong>ses son, respectivam<strong>en</strong>te:<br />
• C<strong>la</strong>se QuantitativeCharacteristicOfAGiv<strong>en</strong>System. Por<br />
ejemplo: type of (p<strong>la</strong>nt)<br />
• C<strong>la</strong>se QuantitativeCharacteristicOfANamedEntity. Por<br />
ejemplo: <strong>de</strong>gree of (D<strong>en</strong>ominator)<br />
• C<strong>la</strong>se<br />
QuantitativeCharacteristicOfANamedEntityOfAGiv<strong>en</strong>Sy<br />
stem Por ejemplo, <strong>la</strong> expresión total m<strong>en</strong>cionada al comi<strong>en</strong>zo <strong>de</strong>l<br />
apartado: <strong>de</strong>gree of (D<strong>en</strong>ominator of (transfer<br />
function of (p<strong>la</strong>nt)))<br />
4.5.9.2 Requerimi<strong>en</strong>tos <strong>de</strong> diseño<br />
La conceptualización <strong>de</strong> los requerimi<strong>en</strong>tos <strong>de</strong> diseño <strong>en</strong> <strong>la</strong> ontología se utilizará<br />
<strong>en</strong> <strong>la</strong> parte dinámica <strong>de</strong> <strong>la</strong> misma. El uso actual <strong>de</strong> <strong>la</strong> misma consiste <strong>en</strong> su<br />
repres<strong>en</strong>tación gráfica como área <strong>de</strong> diseño (<strong>en</strong> el caso <strong>de</strong> <strong>la</strong>s especificaciones <strong>de</strong><br />
régim<strong>en</strong> transitorio).<br />
Para repres<strong>en</strong>tar el conjunto <strong>de</strong> requerimi<strong>en</strong>tos <strong>de</strong> diseño se ha utilizado <strong>la</strong> c<strong>la</strong>se<br />
DesignObjective, que ti<strong>en</strong>e un slot múltiple <strong>en</strong> el que se repres<strong>en</strong>tan los<br />
difer<strong>en</strong>tes requerimi<strong>en</strong>tos <strong>de</strong> diseño. Estos requerimi<strong>en</strong>tos serán instancias <strong>de</strong> <strong>la</strong><br />
c<strong>la</strong>se Frequ<strong>en</strong>cyDomainDesignRequirem<strong>en</strong>t que, a su vez, estará<br />
formada por tres slots: uno <strong>para</strong> recoger <strong>la</strong> característica sobre <strong>la</strong> que se establece<br />
el requerimi<strong>en</strong>to, otro <strong>para</strong> establecer <strong>la</strong> cláusu<strong>la</strong> <strong>de</strong> com<strong>para</strong>ción y otro más <strong>para</strong><br />
recoger el valor <strong>de</strong>seado <strong>para</strong> ese requerimi<strong>en</strong>to <strong>de</strong> diseño.<br />
149