Bayesian semantics for the semantic web

НазваниеBayesian semantics for the semantic web
Размер1.34 Mb.
1   2   3   4   5   6   7   8   9   ...   20
Definition 3: A probabilistic ontology is an explicit, formal knowledge representation that expresses knowledge about a domain of application. This includes:

  1. Types of entities that exist in the domain;

  2. Properties of those entities;

  3. Relationships among entities;

  4. Processes and events that happen with those entities;

  5. Statistical regularities that characterize the domain;

  6. Inconclusive, ambiguous, incomplete, unreliable, and dissonant knowledge related to entities of the domain;

  7. Uncertainty about all the above forms of knowledge;

where the term entity refers to any concept (real or fictitious, concrete or abstract) that can be described and reasoned about within the domain of application.◼

Probabilistic Ontologies are used for the purpose of comprehensively describing knowledge about a domain and the uncertainty embedded to that knowledge in a principled, structured and sharable way, ideally in a format that can be read and processed by a computer. They also expand the possibilities of standard ontologies by introducing the requirement of a proper representation of the statistical regularities and the uncertain evidence about entities in a domain of application. Yet, meeting the main objective of this research effort requires going a step further and also allowing for reasoning upon what now can be represented via probabilistic ontologies.

In the current SW’s scheme, OWL ontologies are used for representing domain information in a way to enable Web services/agents to perform logical reasoning over that information. More specifically, ontologies intended to facilitate logical reasoning by Web services/agents are commonly written using OWL-DL, the decidable subset of OWL language that is based on Description Logics. Writing ontologies in OWL-DL permits the use of DL reasoners such as Racer (Haarslev & Möller, 2001) to perform logical reasoning over its contents. Figure 19 depicts the typical flow of knowledge of a Web agent that is based on logical reasoning.

  1. Typical Web Agent’s Knowledge Flow – Ignoring Uncertainty

In the situation depicted by the figure, the Web agent (here assumed as using Racer as its reasoning engine) receives new data and uses the domain information stored in the knowledge base (an OWL ontology) to perform logical reasoning. Its output is the enhanced knowledge that results from the logical reasoning process, and can be used as a means to answer queries posed to the Web agent and/or to update the knowledge base. As an example from our case study, suppose that a logical reasoner receives information that a newly detected starship is a (say) Keldon-Class Warship operated by the Cardassian species. Then, it verifies the axioms and restrictions conveyed in the Enterprise’s Star Trek ontology that an individual of class Starship possessing these properties could only be a foe. As a result, the reasoner classifies that individual as being a member of the subclass Foe and returns the new knowledge to the system.

Among the possibilities of logical reasoning is the ability to infer whether a given concept is a subclass of another (i.e. subumption), whether the definitions of a class will make it impossible to have any instances (i.e. consistency), and others that make OWL-DL ontologies very a powerful tool for the SW. Not surprisingly, most SW ontologies are being developed using OWL-DL.

Still, as we have emphasized in the previous Chapters, the above-mentioned features of logical reasoning are only possible when complete information in available to the reasoner. In our example, factors such as distance, ambiguities on the received data, overlapping characteristics among starship classes and other sources of uncertainty would most likely prevent any definitive conclusion about the starship type or operator species to be draw.

Sources of uncertainty are the rule in open environments such as the SW, which reinforces the use of probabilistic ontologies for both representing uncertain knowledge and reasoning with it. Figure 20 depicts the same Web agent’s knowledge flow, but this time incorporating the concepts of a probabilistic ontology and a plausible reasoner.

As it is shown in the picture, the knowledge base now consists of a PR-OWL ontology. This expanded depiction of the starship domain includes all the concepts of the previously depicted OWL ontology plus the uncertain information that could not be expressed in a principled way with a standard OWL ontology. Also, new evidence that would be simply discarded by the logical system (e.g. the recently detected starship has 90% chances of being operated by Cardassians) can now be accepted and considered in the reasoning process. Since the Web agent now uses a probabilistic reasoner (Quiddity*Suite in this example), each and every piece of evidence would be used to upgrade the system’s knowledge. In short, all the advantages of a Bayesian probabilistic system that were covered in the previous chapters are now available.

  1. Typical Web Agent’s Knowledge Flow – Computing Uncertainty

The result of the added capabilities, as implied in the enhanced knowledge box, is the system’s ability to keep the best estimate possible for its queries given the previous knowledge and all the available data at any given time. This new aspect opens the opportunity for solving many SW problems that logical systems so far have been unable to solve, such as schedule matching, optimal decision with incomplete data, etc.

In the scheme depicted in Figure 20, there are two aspects that cannot be implemented today. First, there is no Semantic Web language capable of representing probabilistic ontologies in a principled way and, second, after such a language is developed there will be no probabilistic reasoner specifically designed to perform the reasoning services using the newly developed language.

In this dissertation, we have tackled the first aspect with the development of PR-OWL, while addressing the second problem by defining a set of rules for translating a MENB model to a Quiddity*Suite model. This was not a trivial process, and the following sections are intended to explain what we have done to “clear the path” for probabilistic ontologies.

Our first major issue was the fact that standard MEBN does not have built-in support for the complex elements of the OWL language, preventing any attempts of a direct PR-OWL implementation. For instance, standard MEBN is untyped, which means there is no built-in support for PR-OWL probability distributions to depend on types, or for representing type uncertainty, both highly desirable features for a probabilistic ontology. In section 4.1 we present our solution to this problem: the development of an extended version of MEBN logic that incorporates all the desirable features missing in the standard logic.

The second and last Section of this chapter is devoted to explain how we addressed another major issue preventing us to develop PR-OWL: there is no “off-the-shelf” probabilistic reasoner that implements all MEBN features. By the time of our research, Quiddity*Suite was rapidly reaching a stage in which most if not all MEBN features would be implemented, so we developed a set of rules that allowed us to use it as a MEBN implementation and a valid PR-OWL reasoner.

1.18A Polymorphic Extension to MEBN

The most obvious difference between a typed and an untyped logic is the addition of a type label declaration. However, just adding a type label to MEBN logic will not provide it with the advantages of type systems, such as efficient inference based on inheritance, increased readability, conciseness, etc. Developing a typed version of a probabilistic first-order logic involves creating a coherent set of standard definitions and inference rules that collectively form a consistent type system.

A common way to declare types is to define a monadic predi­cate for each type; the predicate is true of entities of the given type and false otherwise. According to Sowa (2000, page 473), a type system adds no expressive power to a knowledge representation language, in that every theorem and proof in a typed logic will have a counterpart in its untyped ver­sion. Given the formal equivalence in expressiveness between typed and untyped logics, one might wonder why typed logics are so much more popular. This popularity can be explained by their advantages in terms of tractability and ease of use.

FOL provides the theoretical foundation for the type systems used in popular object-oriented and relational languages. The popularity of typed logics reflects the prevalence of types in informal reasoning. Classification of objects in terms of the purposes for which they are used typically results in a more or less well-defined type system (Cardelli & Wegner, 1985). The advantages of languages based on a typed logical system are usually related to code optimization and to less error-prone syntax. A number of authors have developed semantics for typed languages (Milner, 1978; Damas & Milner, 1982; Mitchell, 1984).

Standard MEBN is untyped, but a typed extension can provide a sound mathematical basis for representing and reasoning under uncertainty in typed domains, including domains of unbounded or infinite cardinality. Among the advantages of a MEBN-based type system is the ability to represent type uncertainty. As an example, suppose there are two different types of space traveling entities, starships and comets, and incomplete information is given about the type of a given entity. In this case, the result of a query that depends on the entity type will be a weighted average of the result given that the entity is a comet and the result given that it is a starship.

Further advantages of a MEBN-based type system include the ability to refine type-specific probability distributions using Bayesian learning, assign probabilities to possible values of unknown attributes, reason coherently at multiple levels of resolution, and other features related to representing and reasoning with incomplete and/or uncertain information.

Therefore, defining standard syntax and semantics for a MEBN-based type system would combine the advantages of FOL-based type systems with the ability to express and reason with uncertainty, including uncertainty about the type of an entity.

In order to provide a typed version of MEBN, two main changes are proposed here: (1) modify the definition of an MTheory provided in Laskey (2005) to allow for a random variable to have multiple home MFrags (i.e. polymorphism), and (2) include a set of built-in MFrags that provide a standard procedure for defining domain-specific types and subtypes.

As a basic assumption, types are arranged in a tree-structured hierarchy (thus excluding multiple inheritance for the present). The types immediately below a given type (e.g. Starship) are called its subtypes (e.g. MilitaryStarship and CivilianStarship are subtypes of Machine). The next-higher type to a given type is called its parent type (e.g. the parent type of MilitaryStarship is Starship). For our present proposed type system, a given type can have only one parent type. It is relatively straightforward to extend the system being presented here to a type system with multiple-inheritance.

Figure 21 shows the Star Trek MTheory from Figure 12 with the addition of the Transporter Mfrag, illustrating the effects of a polymorphic, typed version. This new generative MFrag conveys information on Enterprise’s ability to beam a person or an object to a close planet.

  1. Star Trek MTheory with the Transporter MFrag – Untyped Version

A Transporter is the device that performs the beaming process (in “theory, a form of molecular transport), which depends on the distance between Enterprise and the target planet, and on whether the defense shields are activated. Usually, the shields will be up when the potential harm of any starship on the vicinities of Enterprise reaches a certain threshold (infered by the instances of node HarmPotential(st, t) for each nearby starship).

Both MTheories have an Entity MFrag used for declaring the possible types of entity that can be found in the model, and an IsA MFrag for allocating a type label to a given entity. This is an example of a situation in which the modeler wanted a type system so she had to build her own scheme for defining entity types. Given the popularity of type system, we might expect other modelers to specify their own Type and IsA MFrags, possibly resulting in many different, incompatible implementations of MEBN-based type system. A standard typed extension to MEBN frees each implementer from having to define her/his own type systems and thus supports a greater level of interoperability.

Even with the modeler defining her/his own type system, situations in which a node such as PlanetDistanceFromOwn(p, t) cannot be named DistanceFromOwn(p, t) because there is another node with that name are very likely to happen. According to the unique home MFrag restriction, one node cannot have two home MFrags so a different name would have to be issued for any node that measures the distance from an object to the Enterprise. In short, the MTheory in Figure 21 does not have subtyping, polymorphism, or inheritance, features that are often useful for modeling complex, real-life problems. As shown in the next section, the extended version proposed in this work includes these features.

1.18.1The Modified MTheory Definition

In order to provide a typed version of MEBN logic, the definition of a generative MTheory is modified here to allow a random variable to have more than one home MFrag. The unique home MFrag restriction is relaxed to allow multiple home MFrags for a node, provided that if a node is resident in two MFrags then either: (1) the two contexts in the different MFrags are entirely disjoint, or (2) one context is strictly contained in the other. Distributions defined for a type are inherited for all its subtypes, except that distributions defined in more general contexts are overridden by distributions defined in more restricted context.

As a means of providing a standard support for typing, typed MEBN includes the four MFrags depicted in Figure 22 among the built-in MFrags.

  1. Built-in MFrags for Typed MEBN

The Type MFrag. The Type MFrag has three resident nodes and no input or context nodes. It lays out the core structure for the type system and provides the basic support for the domain-specific type definitions. The uppermost resident node, (e) (the identity random variable), is parent of the other two nodes and has all valid entities of a given domain as its states. As with standard MEBN, the only values that may have non-zero probability are e (for meaningful entities) and  (for identifiers that refer to meaningless or nonexistent entities). Type(e) is domain-specific (i.e., defined by the knowledge engineer) and its states include three special types that are standard to all polymorphic MEBN models plus the domain-specific types defined by the knowledge engineer.

 The special types are: (1) TypeLabel, which includes the labels of all domain-specific types and subtypes; (2) Boolean, which includes the truth-values T, F, and ; (3) CategoryLabel, which includes labels for RVs whose domain is a list of categorical values; and (4) Positive­Number, which is used for virtual counts (see below).

Finally, ParentType(e) defines the type of which e is a subtype. When e is replaced by a unique identifier of a TypeLabel entity, then ParentType(e) must have a unique TypeLabel entity as its value if the substituting entity type has a parent type. In addition, if e is replaced by a unique identifier of a TypeLabel entity at the level of the type hierarchy immediately below the root Entity, then ParentType(e) will have value Entity; and furthermore, Parent­Type(Entity) = Entity.
1   2   3   4   5   6   7   8   9   ...   20


Bayesian semantics for the semantic web iconQueries: Enabling Querying for Semantic Associations on the Semantic Web

Bayesian semantics for the semantic web iconSemantic Web : a guide to the Future of xml, Web Services, and Knowledge Management

Bayesian semantics for the semantic web iconThe 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

Bayesian semantics for the semantic web iconЗадача: Предоставляет пользователю унифицированную среду содержащую сервисы и функциональности, варьирующиеся от информационных сервисов и сервисов извлечения
По аналогии с Semantic Web, Semantic Grid может быть определен как расширение современных grid, где информация и сервисы имеют четкий...
Bayesian semantics for the semantic web iconThis document contains a list of references to publications and reports about Bayesian Net technology, and especially Bayesian Net applications. The report will

Bayesian semantics for the semantic web iconValentina Janev, Sanja Vranes, Semantic Web Tools and Technologies for Competence Management, Lambert Academic Publishing GmbH, isbn: 978-8454-4166-5, Sarbrucken, Germany, 2011

Bayesian semantics for the semantic web iconИнтеллектуальное реферирование: онтологический подход и его реализация в решениях Ontos
Обсуждению вопросов создания системы реферирования под управлением онтологий, разработанной в рамках решений Ontos для Semantic Web,...
Bayesian semantics for the semantic web iconWeb dizains web design
Основные компоненты web-страницы и способы их визуального представления на страницах сайта
Bayesian semantics for the semantic web iconDependency Tree Semantics and Underspecification

Bayesian semantics for the semantic web iconSemantics of contour lines' spatial relation

Разместите кнопку на своём сайте:

База данных защищена авторским правом © 2014
обратиться к администрации
Главная страница