Bayesian semantics for the semantic web

НазваниеBayesian semantics for the semantic web
Размер1.34 Mb.
1   ...   10   11   12   13   14   15   16   17   ...   20

Type: Object property


This is the inverse of the hasProbAssign object property and links one individual probability assignment to its respective probability distribution table.


Type: Object property


This object property links a probability distribution to its respective RV (resident node). Note that this property is functional, since each probability distribution in a MFrag defines a unique RV.

The inverse of this property is hasProbDist.


Type: Object property


This object property links one ordinary variable to the Skolem constant that represents that ordinary variable in quantified expressions. The property is inverse functional, since one Skolem constant can represent only the group of entities that can be replaced with that ordinary variable in the model.

The inverse property is representsOVar.


Type: Datatype property


This datatype property defines how a given declarative probability distribution is expressed. Each probability distribution can be expressed in different formats, and each format is defined by this datatype property. Possible formats include Netica tables, Netica equations, Quiddity formulas, MEBN syntax, and others. However, the declaration itself is stored in the hasDeclaration datatype property as a string so parsers will have to know how to deal with the specific text format of each declaration.


Type: Object property


This object property links an individual of class Node to the MFrag(s) that have this node as a resident node.

The inverse property is hasResidentNode.


Type: Object property


This object property relates one Skolem constant (i.e. an individual from class Skolem) to the MFrag in which it is defined.

The inverse of this property is hasSkolem.


Type: Object property


This object property links one instance of class OVariable to type of the entity that can substitute it. Each argument of a RV has its expected type defined within the home MFrag of that RV. In PR-OWL, the type restrictions are defined directly through the OVariable using the isSubsBy property. One MFrag can have many OVariables (which can be themselves linked to many SimpleArgRelationships) but each OVariable has a unique type, which is explicitly defined by the type of the entity that can substibute that OVariable.

This object property is the inverse of subsOVar.


Type: Object property


This is the inverse of hasType object property, and basically lists all the MEBN entities that have its respective type defined by that specific individual of either the MetaEntity class or the ObjectEntity class.


Type: Object property


This object property links a Skolem constant (i.e. an individual of class Skolem) to the ordinary variable it represents in a quantifier expression. The property is functional since each Skolem constant represents only one ordinary variable in the model.

The inverse property is isRepBySkolem.


Type: Object property


This object property assigns MetaEntity individuals in order to define the type of the substituters for each MFrag ordinary variable.

Its inverse property is the functional isSubsBy.

    1. Naming Convention (optional)

For naming purposes, PR-OWL elements can be partitioned in two major groups: Entities and all the other elements. This distinction comes from the fact that the second group is basically a set of classes that provide the support for the probabilistic part of an ontology. That is, the second group is the backbone of the MEBN-based probabilistic representation that collectively form the PR-OWL semantics. As a result, all of that supporting set elements are linked to an MFrag, which is the basic structure of a MEBN model, and a great level of consistency and straightforwardness can be achieved by adopting a naming convention that acknowledges this fact.

Therefore, a very simple, optional naming convention was used in this research and has proved to be an important asset for keeping consistency and making maintenance of the model easier. In addition, future implementations geared to facilitate the creation / edition of probabilistic ontologies would certainly keep the majority of those supporting elements hidden from the normal user so it seems reasonable that such a system performs an automatic naming for those hidden elements.

Non-Entity elements

The convention adopted was based on blocks divided by underscore characters, while multiple words within a block should be separated using the “camelback” notation (e.g. KeepingTheFirstLetterCapitalized). Also, an ordering among the blocks should be followed to enable any reader aware of the notation to infer the meaning of each element on the basis of its name only. The general format is:

First block - MFrag: First letter(s) of the MFrag to which the element is linked. If there are two MFrags with the same first letter then subsequent letters of the name should be used (non-capitalized) until the ambiguity is resolved.

Second block – Name/relationship: name of the element or of its related node. Usually, names of OVariables and Nodes are not abbreviated, while the longer names of context or input RV terms should have most of its elements abbreviated.

Third block – Type (optional): type of an element or of its related node. This is an optional block that has only one, non-abbreviated and non-capitalized word. Standard types: context, input, ddecl (default declarative distribution), decl (non-default declarative distribution), dtable (PR-OWL Table default distribution), table (PR-OWL Table non-default distribution), cond (conditionant).

Fourth block – Discriminator (optional): This block should be used to discriminate similar elements. When more than one number is used, separation is made using a dot (e.g. 2.4 meaning the second of four elements in an argument relationship or the second ).

Here are some examples and their respective intended meaning:

SRD_sr: Ordinary variable “sr” from the Sensor Report Data MFrag.

S_CloakMode: Resident node “Cloak Mode” from the Starship MFrag (if an input or context node then a type block would be necessary).

Z_CloakMode_input: Input node “Cloak Mode” from the Zone MFrag.

Z_ZoneEShips_ddecl_Netica: Default declarative distribution of node ZoneEShips from Zone MFrag, written in Netica format.

Z_TprevPrevT_context: Context node “(tprev = Prev(t))” from the Zone MFrag.

Z_TprevPrevT_inner_prevT: Inner term “Prev(t)” of context node “(tprev = Prev(t))” from the Zone MFrag.

Z_TprevPrevT_inner_prevT_2.2: Second argument (out of 2) from the argument relationship (ArgRelationship) of the inner term “Prev(t)” of context node “(tprev = Prev(t))” from the Zone MFrag.

Z_ZoneEShips_table_4.3.5: Probabilistic assignment for the fourth state of the variable ZoneEShips from the Zone MFrag, given the third state of one of its parents and the fifth state of its other parent (both states are represented as CondRelationships, which include the name of the parent and its respective state).

DTS_OpSpec_inputCond_2.3: Conditionant relationship representing the second state out of three states of input node OpSpec from the DangerToSelf MFrag. Note that the type block has two values (input and cond) so the “camelback” notation is used to separate those values inside the same block


MFrags – Names of MFrags will be stated in the first block (not abbreviated) followed by the suffix “_MFrag”. Example: Starship_MFrag, DangerToSelf_MFrag.

MTheories – Names of MTheories will be stated in the first block (not abbreviated) followed by the suffix “_MTheory”. Example: StarTrek_MTheory, Confederation_MTheory.

Built-In RVs – PR-OWL built-in RVs cannot be changed by the probabilistic ontology editor and should be used as is.

Entity elements

Each of the four types of entity element has its own peculiarity:

Boolean RV States: These are built-in to PR-OWL, so cannot be changed.

Categorical RV States: Names of categorical states should be preceded by a block containing the first letters (capitalized) of the RV (node) they are state from. If there are two RVs with the same first letter then subsequent letters of the name should be used (non-capitalized) until the ambiguity is resolved. The name of the state itself is up to the ontology engineer; provide that the unique naming assumption is respected.

Meta Entities: Built-In Meta Entities cannot be changed. Domain-specific Meta Entities should have the same name of their respective object class followed by the suffix “_Label”. Example: the Meta Entity that designate the type of individuals of class Starship should be named Starship_Label.

Object Entities: The ontology engineer is free to choose any naming for the classes of object entities and for its respective individuals, provide that the unique naming assumption is respected.

    1. PR-OWL Upper-Ontology Code

The following OWL code includes all the elements of the PR-OWL extension formatted as an upper ontology.







>Ordinary variables are placeholders used in MFrags to refer to non-specific entities as arguments in a given MFrag's RVs.



>Individuals of this class represent the random variables from MEBN logic's built-in MFrags: logical connectives, quantifiers, the equality random variable. Likewise their function in MEBN logic, these individuals allow PR-OWL ontologies to represent a rich family of probability distributions over interpretations of first-order logic.

Note that MEBN's built-in Indirect Reference MFrag is already represented in PR-OWL via its recursive scheme of building complex formulas.


>In general, MFrags impose constraints to the type of arguments each of its resident RVs should accept. The individuals of the Context class represent these types of constraints.

In PR-OWL, the class Context is the only subclass of the Node class that accepts composite RV terms as arguments (that is, uses the complete ArgRelationship instead of the more restricted SimpleArgRelashionship).

A context node is either satisfiable or not, which means its possible states are instances of the BooleanRVStates class.

>Domain MFrags is the subclass of class MFrag that includes all the domain-specific MFrags. It is disjoint with class Finding_MFrag. All generative MFrags created by the ontology engineer (i.e. the domain expert) are members of this class.


>The conditional relationship class is a reified property representing a (parent) node and one of its possible states. Individuals of this class are used to built PR-OWL probabilistic distribution tables. Each cell of such a table corresponds to a probability assignment of a possible value of a node given one combination of the states of its parents. Each individual of class CondRelationship represents one parent/state pair, so a probability assigment is conditioned by a set of CondRelationship pairs (one for each parent node).


>This class is meant to represent the probability distributions that are defined in an MFrag to each of its resident nodes (random variables). A probability distribution can be described using a proprietary declarative format, such as a Netica table or a Quiddity function, or via an PR-OWL table (which has probability assigments as its cells).

>An PR-OWL table has all the probability assignments for each state of a RV stored in a xsd:decimal format (future implementations might use the pr-owl:prob format, but currently that means incompatibilities with OWL, which has no support for PR-OWL custom datatypes).

This format for storing probability distributions cannot represent complex cases for which only formulas can represent a probability distribution (e.g. a node that have a variable number of parents) and usually incurs in huge ontologies, since each table can have many cells and each cell is an individual of the ProbAssign class. Therefore, PR-OWL tables are only recommended for the simplest models in which the maximum level of compatibility is desired.


>Finding MFrags are used to convey information about findings, which is the default way of entering evidence in a MEBN MTheory so a probabilistic algorithm can be applied to perform inferences regarding the new evidence. They have no context nodes, only one input and one resident node.



>The class ObjectEntity aggregates the MEBN entities that are real world concepts of interest in a domain. They are akin to objects in OO models and to frames in frame-based knowledge systems.



>In PR-OWL, an input node is basically a "copy" of a resident node that is used as an input in a given MFrag. Thus, each individual of class Input is linked with an individual of class Resident via the property isInputInstanceOf.

1   ...   10   11   12   13   14   15   16   17   ...   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
обратиться к администрации
Главная страница