Скачать 1.34 Mb.
1.19.2Concepts with a More Complex Translation
In Subsection 4.2.1 we intentionally omitted some MEBN concepts that do appear in the Star Trek MTheory, most notably the context nodes and the ordinary variables. Also, we avoided specific cases of the concepts already cited, such as situations in which an input note might generate multiple instances of itself. The reason of those omissions is the intrinsic complexity of those cases, which demands a more elaborate discussion.
Context nodes are a powerful aspect of MEBN logic that allow specifying carefully defined situations in which a given MFrag is valid. Some of the more common context nodes are relatively easy to express in Quiddity*Suite, while others present some issues requiring relatively complex workarounds. Those cases are addressed in this Subsection.
The most common use of context nodes involves the specification of the types of the entities in a given MFrag. In an entity cluster structure, all MFrags have the cluster’s subject entity as their main attribute, so they will include an ordinary variable representing that subject entity and a context node making that representation explicit. A brief verification on the Star Trek MTheory in Figure 24 will show that all MFrags within each cluster have a node such as IsA(SubjectEntity, ordvar). As an example, all MFrags within the Starship cluster have an IsA(Starship, …) context node.
The other Isa(TypeLabel, ordvar) in each MFrag are used to define the type of the instances that can substitute each ordinary variable. As a practical rule, for each of those “extra” Isa(TypeLabel, ordvar) a pointer slot would have to be created in the frame. Of course, only one pointer slot is needed so if there is one already then it is not necessary to create another. As an example from the Sensor Report cluster, since there is already a slot pointing to frame Starship (directly created because of the Subject(sr) resident node) then when evaluating the context node IsA(Starship, st) in the Sensor Report MFrag there will be no need to create another pointer slot.
One exception to the above general rule is the IsA(TimeStep, ordvar) context nodes, which should not generate a pointer slot. The intended meaning of an entity of type TimeStep is to indicate time recursion, which has a special treatment in Quiddity*Suite. Figure 26 illustrates an example of an MFrag (Zone, the unique MFrag in Zone Cluster) with temporal recursion and its respective frame counterpart. There are three context nodes and two input nodes expressing that recursion in MEBN. The two IsA(TimeStep, ordvar) context nodes are used to define the type of the ordinary variables t and tprev, while the remaining context node uses the Prev(t) random variable to specify that variable tprev is the predecessor of variable t in the ancestor chain of that time recursion. The two input nodes are t = !T0 and ZoneMD(z, tprev). The first “anchors” the recursion, while the latter makes it explicit that the distribution of ZoneMD(z, t) depends on its immediate ancestor in the recursion ZoneMD(z, tprev). These five nodes are expressed by two specific elements in the ZoneMD slot. The first is its Parents facet, which contains zoneMD.PREV, where the suffix .PREV indicates that this slot’s distribution depends upon its ancestor. The second is the initialState facet, which contains the distribution for the first instance of the ancestor chain.
As a general rule, MEBN recursions will follow this pattern of three context nodes defining two ordinary variables and their precedence, and two input nodes for “anchoring” the recursion and declaring the recursive resident node’s dependence over its predecessor. Such pattern should then be translated to Quiddity*Suite using the .PREV suffix and the initialState facet accordingly.
Apart from defining types of ordinary variables and establishing recursive patterns, context nodes are used to specify how the process of SSBN construction will occur. In other words, context nodes can be seen as logic rules that define the conditions under which instances of the random variables of an MFrag will be created during the process of SSBN construction. As an example from the Zone MFrag of Figure 26, the context node z=StarshipZone(st) specifies a restriction on instances of Zone and Starship entities that can be substituted for occurrences of the ordinary variables z and st, respectively. Specifically, if the substitution is to be valid, the value of the attribute StarshipZone for any Starship instance substituted for st must be equal to the Zone instance substituted for z. The only way of enforcing this restriction in the current version of Quiddity*Suite is by encoding it procedurally in the entity creation process. In other words, it is not possible to express this kind of restriction in the frame definition alone, so we have to enforce it via the entity creation process, or A-box construction procedure.
This limitation in expressing context nodes in Quiddity*Suite is akin to the DL limitation discussed in the end of Subsection 1.8.1 concerning the representation of constraints on the instances that can participate in a relationship. That is, just as we cannot express certain constraints using only the T-Box in a DL representation, we cannot represent those same constrains in the frame structure of a Quiddity*Suite model.
The next version of Quiddity*Suite will have the ability to use Prolog-like rules for automatically controlling A-box construction to enforce the restrictions expressed in the context nodes of an MFrag. Unfortunately, the new version will not be released in time to be incorporated into this research. As a result, we enforced context restrictions procedurally in our model’s function definitions and executable module, both available in Appendix A.
As a general rule, context nodes restricting the conditions under which the instances of an MFrag should be created can only be expressed in Quiddity*Suite in a programmatically fashion during the creation of the instances. The inclusion of logical rules will allow a modeler to define the rules prior to the A-box creation process, thus introducing a great level of automation in a procedure that we had to perform by carefully programming the A-box creation itself.
The last specific translation issue to be addressed when translating MTheories to Quiddity*Suite is the case in which a node has many possible parents. One example of such situation is illustrated in Figure 26, where the resident node ZoneMD(z, t) has the input node CloakMode(st) as its parent and the restrictions expressed in the context nodes allow this input to have many possible instances. In other words, given the valid context for the Zone MFrag, all starships that happen to be in zone z will be parents of ZoneMD(z, t). Thus, we have a variable number of parents that depends on how many starships are in a given zone.
The problem is that Quiddity*Suite doesn’t have support for defining probability distributions for an undefined number of parents, so specifying a distribution such as the one we have shown in Figure 8 is not possible at this time. Therefore, in order to model this kind of situation we had to resort to a modeling trick in which we created a “collector node” in Zone MFrag and used Quiddity’s MaxDistribution to handle the undefined number of parents.
In frame Zone, the slot pointing to frame Starship is the starship slot. Usually, an external parent of slot zoneMD would be listed using the pointer.parent format, such as starship.cloakMode in this case. However, we created an intermediate node called anyStInCloakMode which has starship.cloakMode as a parent. This node has the MaxDistribution as its probability distribution so it can handle multiple parents. Then, the “collector” node anyStInCloakMode, and internal node to the Zone MFrag is listed as a parent of zoneMD slot. The intermediate node was necessary because the MaxDistribution accepts only one parent in its list, and ZoneMD has more than one parent so it wouldn’t work with that distribution.
As a general rule, if the variable number of parents of a resident node is generated from one input node only and this is its only parent, then it is possible to use the MaxDistribution directly (i.e. use the same rules for input parents defined in Subsection 4.2.1). Else, the scheme of an intermediate, “collector” node is necessary. In any case, only special distributions such as the MaxDistribution are allowed. In the Starship model, the MaxDistribution was used in place of the one we defined in the pseudo-code of Figure 8.
1.19.3Use of Comments and Other Aspects of Quiddity*Suite
In order to facilitate the translation between MEBN representation and Quiddity*Suite Models, we have developed a list of markups that should be included as comments in Quiddity*Suite models. The information inside each markup would then be inserted in specific concepts in a PR-OWL ontology. Table 4 brings a list of those markups and their respective PR-OWL concepts.
|Queries: Enabling Querying for Semantic Associations on the Semantic Web||Semantic Web : a guide to the Future of xml, Web Services, and Knowledge Management|
|The Semantic Model contains a high level description of the Actions that operate on the objects and attributes in the model. This document does not describe the mapping of the semantics onto a specific protocol or network environment||Задача: Предоставляет пользователю унифицированную среду содержащую сервисы и функциональности, варьирующиеся от информационных сервисов и сервисов извлечения |
По аналогии с Semantic Web, Semantic Grid может быть определен как расширение современных grid, где информация и сервисы имеют четкий...
|This document contains a list of references to publications and reports about Bayesian Net technology, and especially Bayesian Net applications. The report will||Valentina Janev, Sanja Vranes, Semantic Web Tools and Technologies for Competence Management, Lambert Academic Publishing GmbH, isbn: 978-8454-4166-5, Sarbrucken, Germany, 2011|
|Интеллектуальное реферирование: онтологический подход и его реализация в решениях Ontos|
Обсуждению вопросов создания системы реферирования под управлением онтологий, разработанной в рамках решений Ontos для Semantic Web,...
|Web dizains web design|
Основные компоненты web-страницы и способы их визуального представления на страницах сайта
|Dependency Tree Semantics and Underspecification||Semantics of contour lines' spatial relation|