slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Анализ мотивации, целей и подходов проекта унификации языков на п PowerPoint Presentation
Download Presentation
Анализ мотивации, целей и подходов проекта унификации языков на п

Loading in 2 Seconds...

play fullscreen
1 / 112

Анализ мотивации, целей и подходов проекта унификации языков на п - PowerPoint PPT Presentation


  • 168 Views
  • Uploaded on

Анализ мотивации, целей и подходов проекта унификации языков на правилах RIF. Калиниченко Л.А., Ступников С.А. (ИПИ РАН) Симпозиум «Онтологическое моделирование», КФУ, 11-12 Октября 2010 г. План рассмотрения. Унификация языков, интеграция информационных ресурсов, интероперабельность

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Анализ мотивации, целей и подходов проекта унификации языков на п' - yori


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Анализ мотивации, целей и подходов проекта унификации языковна правилах RIF

Калиниченко Л.А., Ступников С.А.

(ИПИ РАН)

Симпозиум «Онтологическое моделирование»,

КФУ, 11-12 Октября 2010 г.

slide2
План рассмотрения
  • Унификация языков, интеграция информационных ресурсов, интероперабельность
  • Цели проекта RIF
  • Языки на правилах и их применения: краткий исторический экскурс
  • Логические модели рассуждений
  • Семантики логических программ
  • Языки и системы ЛП, оказавшие существенное влияние на RIF
  • Примеры использования RIF и системы ЛП в области интересов группы RIF WG
  • Требования к RIF
  • Обзор основных решений RIF
  • Выводы
slide3
Унификация языков, интеграция информационных ресурсов, интероперабельность
slide4
Унификация языков, интероперабельность информационных ресурсов
  • Требуют унификации: языки реляционных и объектных баз данных, онтологического моделирования, представления слабо структурированных, графовых, мультимедийных данных, представления баз знаний, логического программирования, дедуктивные языки запросов к базам данных, спецификации потоков работ, спецификации интерфейсов программных ИР, языки со специализированной семантикой (например, для выражения темпоральных, пространственных моделей), языки для определения нечетких, вероятностных представлений, языки концептуального моделирования и метамодели, и многие другие.
  • Примеры расширяемых унифицирующих языков – СИНТЕЗ
  • Программы на правилах – новый вид ИР , унификация ЯП
  • Цель RIF: создание расширяемого унифицированного семейства языков на правилах
  • Применение подхода должно быть общим, не ограничиваться Вебом
why rules
Why rules
  • The use of rules for knowledge representation and intelligent information systems dates back over thirty years.
  • By now it is a mature technology with decades of theoretical development, practical and commercial use.
  • The accumulated experience in this area exceeds the experience gathered with the use of Description Logics and the field is arguably more mature when it comes to rules
  • The mature technology for rule-based applications is based on logic programming and nonmonotonic reasoning (LPNMR)
  • Interesting that SQL, arguably the most important rule-based language, has LPNMR as its foundation
  • To exploit the full potential of rule-based approaches, the business rules and the Semantic Web communities have started to develop solutions for reusing and integrating knowledge specified in different rule languages (such as http://www.w3.org/2005/rules/wg/wiki/List of Rule Systems)
slide7
Концепция RIF
  • Рабочая группа W3C RIF WG: с 2005 г.Задача:
    • Обеспечить использование потенциала, накопленного при создании и использовании различных языков и систем на правилах
    • Совместимость с RDF и OWL
  • Цель: создание унифицированных диалектов на правилах, в которые существующие языки на правилах могли быть отображены с сохранением семантики , позволяя правила, созданные в рамках некоторого приложения, публиковать, использовать совместно с другими правилами, повторно использовать в других приложениях и других машинах
  • Унифицированный язык представляется как семейство диалектов, которые имеют общее ядро (корневой диалект) и совокупность расширяющих его диалектов
  • Для полновесного включения каждого языка на правилах в совокупность интероперабельных языков достаточно снабдить соответствующую систему программирования двумя сохраняющими семантику преобразователями – из собственного языка в диалект (роль поставщика) и из диалекта в собственный язык (роль пользователя)
slide8
Принятие стандарта
  • 22 June 2010 W3C published a new standard for building rule systems on the Web. Declarative rules allow integration and transformation of data from multiple sources in a distributed, transparent and scalable manner. The new standard, called Rule Interchange Format (RIF), was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. The six new standards are:
  • RIF Core Dialect, which provides a standard, base level of functionality for interchange
  • RIF Basic Logic Dialect and RIF Production Rule Dialect provided extended functionality matching two common classes of rule engines
  • RIF Framework for Logic Dialects describes how to extend RIF for use with a large class of systems
  • RIF Datatypes and Built-Ins 1.0 borrows heavily from XQuery and XPath for a set of basic operations
  • RIF RDF and OWL Compatibility specifies how RIF works with RDF data and OWL ontologies
slide9
Языки на правилах и их применения: краткий исторический экскурс
slide10
Программы на правилах, классы применений
  • Logic programming has three main classes of application:
    • a general-purpose programming language,
    • a database language,
    • a knowledge representation language.
  • As a programming language, it can represent and compute any computable function.
  • As a database language, it generalises relational databases, to include general  clauses in addition to facts.
  • As a knowledge representation language it is a non-monotonic logic, which can be used for default reasoning  
slide15
Применение логики для представления знанийи решения задач

Basic landmarks:

  • Advice Taker, McCarthy (1958) , KR and theorem-proving
  • Resolution (Robinson, 1965)
  • Procedural against logic approach: Planner (MIT) Winograd1971
  • Procedural interpretation of Horn clauses Kowalski 1974
  • Colmerauer’s development of the programming language Prolog
  • Non-monotonic logics: Naf (Clark, 1978), circumscription ( McCarthy, 1980), default logic (Reiter, 1980), autoepistemic logic (Moore, 1985)
  • Production systems (Neweli, 1973)
  • Agent LP logic (Kowalski and Sadri,1999; Kowalski 2001, 2006)
slide16
Дедуктивные базы данных
  • Green and Raphael (1968): connection between theorem proving and deduction in databases; QA systems
  • First description of bounded recursive queries (can be replaced by nonrecursive equivalents): Minker, Nicolas
  • Distinction between EDB and IDB first emphasized in DADM (1981)
  • Reiter's paper on the closed world assumption (1978)
  • Showing that the least fixpoint of a Horn-clause logic program coincides with its least Herbrand model: Emden and Kowalski, 1976
  • Period of 1984 – 1995: active research and development under the influence of the 5th Gen Computers initiative
  • LDL and LDL++ project at MCC (1984, 1990)
  • ECRC deductive database project
  • DOOD conferences: 1989 (Kyoto), 1991 (Munich), 1993 (Phoenix), 1995 (Singapore), 1997 (Montreux), 2000 (London).
slide20
Логические модели рассуждений

Примеры различных видов (моделей) немонотонных рассуждений:

  • Абдуктивные рассуждения:вид автоматизированного правдоподобного рассуждения
  • Рассуждения на основе умолчания: имеется возможность отказа от предположения умолчания, когда оказывается, что оно неверно
  • Отрицание как неудача: основано на предположении о замкнутости мира
  • Логикаочерчивания (circumscription): действуют предположения здравого смысла, пока нет других указаний
  • Автоэпистемическая логика: представление знаний о знаниях и рассуждения в таком контексте
  • Логика отмены заключений: при рассуждениях заключения не окончательны, они могут быть скорректированы или отменены
  • Логика рассуждений с неопределенностью: например, использование Байесовского формализма в системах правил
  • Теории аргументации: основана на искусстве ведения дебатов, убеждения, применяя логические рассуждения
slide21
NAF и рассуждения о неполной информации
  • В логических формулах наряду с отрицанием как неудачей (not), требуется использование классического (сильного) отрицания (¬)

flies(X) :- bird(X), not excl(X).

bird(X) :- penguin(X).

excl(X) :- penguin(X).

bird(tweety) :-.

penguin(sam) :-.

¬bird(X) :- not bird(X).

¬penguin(X) :- not penguin(X).

¬excl(X) :- not excl(X).

¬flies(X) :- penguin(X).

¬flies(X) :-¬bird(X).

  • Явное определение предположенияCWA (выделенные предикаты). Остальные предикаты - в предположении OWA
classes of programs
Classes of Programs
  • H ← B1 ˄ . . . ˄ Bm ˄ ~Bm+1 ˄ . . . ˄ ~Bn 

where H, Bi are atoms, n, m ≥ 0 and ~Bj are called negation-as-failure literals (NAF literals). if [body] then [head]”, with universal quantification on the outer level.

Specific classes of programs:

  • Normal programs allow the use of classical negation in the head and in the body of a rule. 
  • Definite programs are normal programs where negated atoms and NAF-literals are not allowed in the rules. 
  • Datalog programs, are logic programs where function symbols other than constants are not allowed. Usually it is also required that the rules are safe.
  • Conjunction of literals in the head: shorthand for a number of ordinary rules.
  • Disjunction of literals in the head => disjunctive logic programming
definite programs
Definite Programs

Definite programs (not including NAF literals), definite Horn clause, or Horn rule

H ← B1 ˄ . . . ˄ Bk

The semantics of definite logic programs : the least Herbrand model of a given program. The least Herbrand model is the smallest (w.r.t. set inclusion) set S of ground atoms such that for any rule H ← B1 ˄ . . . ˄ Bk,

if B1 ˄ . . . ˄ Bk ϵ S then H ϵ S.

  • Backwardreasoning, where an atomic query is matched/unified with the head of a rule and replaced by the respective instance of the body
  • Forwardreasoning, where the head of a ground instance of a rule is added to the conclusion set when all body atoms of this rule are already included in the conclusion set.
slide25
Хорновские правила
  • A Horn clause is a clause (a conjunction of literals – atomic formulae (atoms) or their negation) with at most one positive literal in the head

H ← B1 ˄ . . . ˄ Bm ˄ ~Bm+1 ˄ . . . ˄ ~Bn

  • Horn clauses play a basic role in logic programming.
  • A Horn clause with exactly one positive literal in the head is a definite clause.
  • A Horn clause with no positive literals in LP is called a goal clause.
  • The resolution of a goal clause with a definite clause is the basis of the SLD resolution (Selective Linear resolution with Definite clauses).  
  • NAF can be used in a body of clauses. In Prolog NAF is known to be problematic: it may not terminate due to infinite positive recursion; due to infinite recursion through negation; and it may repeatedly evaluate the same clause body literal, leading to unacceptable performance
  • Modern logic programming languages use either the well-founded default negation or the one based on stable models
two philosophically different approaches for lp
Two Philosophically Different Approaches for LP
  • 1. To keep the idea of defining a single model for a program, possibly including also problematic classes of programs with negation. This can be achieved by properly defining which single model should be selected among all classical models of a program. For general normal problems, the most popular semantics is perhaps the one based on the well-founded model
  • 2. To identify a collection of multiple models. This line of research abandons the “dogmatic” requirement of a single model and accepts the possibility of having multiple scenarios compatible with a given program. Stable model: model generation (that is, the computation of the set of preferred models) . This is more than query answering
stable model
Stable Model
  • The intuition behind stable model semantics is to treat negated atoms in a special way. Intuitively, such atoms are a source of “contradiction” or “unstability.” “Stability” can thus be seen as follows: if an interpretation M of P is not self-contradicting, then it is stable.

man(petrov).

single(X) ← man(X), not husband(X).

husband(X) ← man(X), not single(X).

  • where single(petrov) and husband(petrov) are mutually dependent using negation. An SLD resolution algorithm would loop forever when trying to answer the query single(X).
  • This program has two minimal Herbrand models that are stable

M1 = {man(petrov), single(petrov)} and

M2 = {man(petrov), husband(petrov)}

answer set programming asp
Answer Set Programming (ASP)
  • ASP adds constraints, strong negation and disjunction
  • female(X) v male(X) ← person(X)
  • Useful application for strong negation (in combination with weak negation) is to express default rules. For example, we can express that “a bird flies by default” with the rule
  • flies(X) ← bird(X), not¬ flies(X). Here ¬ is a strong negation.
  • not p in the body of a rule can be read (V.Lifschitz) as "p is not believed"
  • broken(left hand, tom) v broken(right hand, tom) - disjunctive fact
  • ok(C) v ¬ ok(C) ← component(C)

states that a component may be in a working condition or not working at all,

asp example
ASP Example
  • In the graph 3-coloring problem, assuming that G = (V, E) is stored using
  • facts node(n) for each n ϵ V and edge(n, n’) for each (n, n’) ϵ E, which gives the data D, the generic specification of solutions PS can be given by the following rules:
  • b(X) ← node(X), not r(X), not g(X)
  • r(X) ← node(X), not b(X), not g(X)
  • g(X) ← node(X), not r(X), not b(X)
  • and the constraints
  • ←b(X), b(Y ), edge(X, Y )
  • ←r(X), r(Y ), edge(X, Y )
  • ←g(X), g(Y ), edge(X, Y )
asp applications
ASP Applications
  • This method has been successfully applied to numerous problems in a range of areas; an incomplete list is
  • diagnosis
  • information integration
  • constraint satisfaction
  • reasoning about actions (including planning)
  • routing, and scheduling
  • health care
  • biomedicine and biology
  • text mining and classification
  • question answering
slide32
Хорошо обоснованная семантика (WFS)
  • The well-founded semantics (WFS) -three-valued logic (true, false, unknown)
  • If an atom is true in the well-founded model of P then it belongs to every stable model of P. The converse, generally, does not hold.
  • For instance, the program

p ← not q

q ← not p

r ← p

r ← q

has two stable models, {p,r} and {q,r}. Even though r belongs to both of them, its value in the well-founded model is unknown.

  • WFS, в отличие от ASP, продуцирует в результате вывода единственное результирующее множество
  • Хорошо обоснованная семантика (WFS) является основой реализации многих систем, прежде всего коммерческих (например, XSB, Ontobroker, Intellidimension, SweetRules, SILK, FLORA)
  • ASP обладает более высокой вычислительной сложностью. Примеры реализаций ASP: Smodels, DLV, Clasp.
slide33
Хорошо обоснованная и стабильная семантики
  • One of the frequently cited difference is that ASP supports reasoning by cases , which is not possible using WFS. Due to the differences in their expressive power, the two paradigms are typically used for different purposes. ASP is ideally suited for solving hard combinatorial programs and such systems usually appear as embedded knowledge base components of imperative programming languages. In contrast, WFS-based systems typically are Turing-complete and can be used as programming languages in their own right.
  • At the same time, it was shown that the WFS can be viewed as a three-valued version of the stable model semantics.
rif f logic
Языки и системы ЛП, оказавшие существенное влияние на RIF (F-Logic)
f logic
Фреймовая логика и язык метапрограммирования (F-Logic)
  • F-logic combines the advantages of conceptual modeling with object-oriented, frame-based languages and offers a declarative semantics
  • F-logic provides a logical foundation for frame-based and object-oriented languages for data and knowledge representation
  • HiLog is a a logical formalism extending Prolog that provides higher-order and meta-programming features in a computationally tractable first-order setting.
  • FLORA-2 is an advanced object-oriented knowledge base language
  • The language of FLORA-2 is a dialect of F-logic with extensions – HiLog and logical updates in the style of Transaction Logic
  • Non-first order, nonmonotonic semantics by interpreting the negation operator as negation-as-failure as well as the semantics of multiple inheritance with overriding
structure of f logic programs
Structure of F-Logic Programs

F-programs specify what each method is supposed to do, define method signatures, and organize objects along class hierarchies.

  • Object definitions may be explicit, that is, given as facts, or implicit, that is, specified via deductive rules.
  • Class-hierarchy declarations, as their name suggests, organize objects and classes into IS-A hierarchies.
  • Signature declarations specify the types of the arguments for each method and the type of the output they produce.
  • In FLORA-2, transactions are expressed as object methods that are prefixed with the special symbol “%". Atomicity of transactions is provided.
f logic37
Схемы в F-Logic
  • Classes are treated as objects and it is possible for the same object to play the role of a class in one formula and of an object in another.
  • Schema information through signature formulas

paper[authors => person, title => string].

journal p :: paper[in vol => volume].

conf p :: paper[at conf => conf proc].

journal vol[of => journal, volume => integer, number => integer, year => integer].

journal[name => string, publisher => string, editors => person].

conf proc[of conf => conf series, year => integer, editors => person].

conf series[name => string].

publisher[name => string].

person[name => string, affil(integer) => institution].

institution[name => string, address => string].

f logic38
Объекты в F-Logic

o_j1 : journal p[title -> ’Records, Relations, Sets, Entities, and Things’,

authors -> {o_mes}, in vol -> o_i11].

o_di : conf p[ title -> ’DIAM II and Levels of Abstraction’,

authors -> {o_mes, o_eba}, at conf -> o_v76].

o_i11 : journal vol[of -> o_is, number -> 1, volume -> 1, year -> 1975].

o_is : journal[name -> ’Information Systems’, editors -> {o_mj}].

o_v76 : conf proc[of -> vldb, year -> 1976, editors -> {o_pcl, o_ejn}].

o_vldb : conf series[name -> ’Very Large Databases’].

o_mes : person[name -> ’Michael E. Senko’].

o_mj : person[name -> ’Matthias Jarke’, affil(1976) -> o_rwt].

o_rwt : institution[name -> ’RWTH Aachen’].

slide39
Примеры запросов
  • ?- student[?M=> person].

finds the set-valued methods that are defined in the schema of class student and return objects of type person

  • ?- student::?C and student[name=> ?T].

returns all the superclasses of class student:

  • ?- person[?M(?Arg)=> integer].

?M would be bound to names of functions(and predicates)

The semantics for this second-order syntax is first order, however. Roughly it means that variables get bound not to the extensional values of the symbols, but to the symbols themselves.

slide43
Реификация

p(a).

q(p(a)).

?- q(?X), ?X.

What happens here is that the proposition p(a) is reified (made into an object) and

so it can be bound to a variable ?X

John believes that Mary likes Sally as follows:

John[believes ->${Mary[likes ->Sally]}].

${...} is the syntax that FLORA-2 uses to denote reified statements

John[believes ->${Bob[likes ->?X] : - Mary[likes ->?X]}].

This sentence reifies a rule (not just a fact) and states that John also believes that

Bob likes anybody who is liked by Mary.

f logic examples
F-Logic examples
  • X: merchandise <- X: Y ˄ Y[ price => ( )] 

defines a derived class, merchandise, that consists of all objects to which the attribute price applies.

  • Lowest superclass of X and Y 

lsup(X,Y)::C ← X::C ˄ Y::C

X::lsup(X, Y)

Y:: lsup(X, Y)

  • Greatest subclass of X and Y 

C::gsub(X,Y) ← C::X ˄ C::Y

gsub(X, Y) :: X

gsub(X, Y)::Y

methods in f logic
Methods in F-Logic

empl[ salary @ year => integer]

person[ birthdate => year]

salary is a function that for any empl-object would return an object in the class integer, if invoked with an argument of class year.

The second clause says that birthdate is an attribute that returns a year for any person-object.

f logic vs dls
F-Logicvs DLs
  • F-logic is computationally complete. On the other hand, expressive F-logic knowledge bases provide no computational guarantees.

Comparing to DL:

  • The exponential complexity of many problems in DLs creates difficulties in reasoning with large ontologies
  • Decidable computations in F-logic with polynomial complexity includes queries without function symbols that are beyond the expressive power of DLs. Furthermore, research in logic programming and deductive database has identified large classes of knowledge bases with function symbols where query answering is decidable

There are two aspects where DLs provide more flexibility:

  • DLs allow the user to represent existential information. For instance, one can say that there is a person with certain properties without specifying any concrete instance of such a person
  • DLs admit disjunctive information into the knowledge base. For instance, one can say that John has a book or a bicycle. The corresponding statement in F-logic is only an approximation: john[has! #:(book or bicycle)] (# - Skolem constant)
rif rif wg
Примеры использования RIF и системы ЛП в области интересов группы RIF WG
c rif wg
Cистемы на правилах в области интересов RIF WG
  • C самого начала проекта RIF следовало позаботиться об установлении взаимодействия с группами создания и поддержки конкретных разнородных языков и системна правилах
  • Группой RIF WG изначально было определено, что rule system is of interest to the RIF WG if it is liable to enter in applications where it will be required to interchange rules (with other rule systems of interest) and to implement a Use Cases.
  • Более 50 предложений примеров использования были получены RIF WG в 2005 г. Эти примеры представляли более 20 различных систем на правилах.
rif 1
Системы на правилах, отобранные для анализа и выработки требований к RIF (1)
rif 2
Системы на правилах, отобранные для анализа и выработки требований к RIF (2)
rif 3
Системы на правилах, отобранные для анализа и выработки требований к RIF (3)
slide52
Категории примеров использования

Список категорий примеров использования выглядит так (ранняя категоризация W3C):

1. Information Integration

2. Decision Support

3. Cross-Platform Rule Development & Deployment

4. Policy-Based Transaction Authorization and Access Control

5. Interchange of Human-oriented Business Rules

6. Publication

7. Third Party Rule-Interchange Services

8. Rich Knowledge Representation

rule interchange format rif intentions
Rule Interchange Format (RIF) intentions
  • RIF is designed to enable interoperability among rule languages in general, and its uses are not limited to the Web.
  • To design a uniform and extensible family of languages (dialects)
  • RIF uniformity: dialects should share as much as possible of the existing syntactic and semantic apparatus
  • RIF Extensibility: it should be possible to define a new RIF dialect as a syntactic extension to an existing RIF dialect, with new elements with additional functionality.
  • Idea behind rule exchange through RIF: syntactic, semantics-preserving mappings from native languages of various rule systems to RIF dialects and back
  • Primary focus: RIF is focused on two kinds of dialects: logic-based dialects and dialects for rules with actions.
slide55
Общие требования к RIF
  • Implementability:
  • Semantic precision:
  • Extensible Format: create new dialects of RIF upwardly compatible.
  • Translators: to implement translators between dialect rule languages and RIF without changing the rule language.
  • Standard components: standard support technologies such as XML parsers and other parser generators, etc.
  • Rule language coverage: RIF must cover the set of languages identified in

the Rulesystem Arrangement Framework (RIFRAF).

slide57
Требования, мотивированные примерами использования (1)
  • Compliance model The RIF specifications must provide clear conformance criteria, defining what is or is not a conformant RIF implementation.
  • Default behavior RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document
  • Different semantics RIF must cover rule languages having different semantics.
  • Limited number of dialects RIF must have a standard core and a limited number of standard dialects based upon that core.
  • OWL data RIF must cover OWL knowledge bases as data where compatible with RIF semantics.
slide58
Требования, мотивированные примерами использования (2)
  • RDF data RIF must cover RDF triples as data where compatible with RIF semantics.
  • Dialect Identification The semantics of a RIF document must be uniquely determined by the content of the document, without out-of-band data.
  • XML syntax RIF must have an XML syntax as its primary normative syntax.
  • XML types RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema.
  • Merge Rule Sets RIF must support the ability to merge rule sets (even written in different rule languages).
  • Identify Rule Sets RIF must support the identification of rule sets.
slide60
Решения RIF
  • Known rule systems fall into three broad categories: first-order, logic-programming, and action rules. These paradigms share little in the way of syntax and semantics. Moreover, there are large differences between systems even within the same paradigm.
  • The approach taken by the Working Group was to design a family of languages, called dialects, with rigorously specified syntax and semantics. The family of RIF dialects is intended to be uniform and extensible.
  • RIF uniformity means that dialects are expected to share as much as possible of the existing syntactic and semantic apparatus.
  • Extensibility here means that it should be possible for motivated experts to define a new RIF dialect as a syntactic extension to an existing RIF dialect, with new elements corresponding to desired additional functionality. These new RIF dialects would be non-standard when defined, but might eventually become standards.
current rif dialects as standards
Current RIF Dialects as Standards
  • RIF-BLD: The Basic Logic Dialectthis dialect corresponds to Horn logic with various syntactic and semantic extensions. The main syntactic extensions include the frame syntax and predicates with named arguments. The main semantic extensions include datatypes and externally defined predicates. Has limited expressiveness that lies within the intersection of first-order and logic-programming systems, it does not support negation.
  • RIF-PRD: The Production Rule Dialect captures the main aspects of various production rule systems. Production rules are defined using ad hoc computational mechanisms, which are not based on a logic.
  • RIF-Core: The Core Dialect. This dialect is a subset of both RIF-BLD and RIF-PRD thus enabling limited rule exchange between logic rule dialects and production rules. RIF-Core corresponds to Horn logic without function symbols (often called 'Datalog') with a number of extensions to support features such as objects and frames as in F-logic, internationalized resource identifiers for concepts, and XML Schema datatypes.
rif framework for logic dialects
RIF Framework for Logic Dialects
  • Started as a classification system (RIFRAF = RIF Rule Arrangement Framework) populated with existing rule languages and systems. 50 use cases were collected by the RIF group applying normative, deductive, reactive rules
  • RIF-FLD specification is unique it presents in a coherent form syntactic and semantic machinery of different logic rule systems after digesting of the respective knowledge
  • RIF-FLD is a very general logic language that includes a great deal of commonly used syntactic and semantic apparatus
  • It purposely leaves certain parameters unspecified to enable designers of concrete dialects to fill in the necessary details
rif framework for logic dialects64
RIF Framework for Logic Dialects
  • A dialect designer can then define the syntax/semantics of a dialect by specializing it from the syntax/semantics of RIF-FLD
  • The RIF framework for logic dialects also supports a variety of rule languages based on non-monotonic theories (including WFS and stable model)
  • For rule interchange between CL and RIF dialects, it is expected that partial RIF-CL mappings will be defined.
  • RIF framework is likely to see several extensions in the future
rif fld main components
RIF-FLD main components
  • Syntactic framework. This framework defines the mechanisms for specifying the formal presentation syntax of RIF logic dialects by specializing the presentation syntax of the framework. This syntax is not intended to be a concrete syntax for the dialects; it leaves out details such as the delimiters of the various syntactic components, parenthesizing, precedence of operators, and the like. Since RIF is an interchange format, it uses XML as its only concrete syntax.
  • Semantic framework. The semantic framework describes the mechanisms that are used for specifying the models of RIF logic dialects. It specifies such semantic notions as models and logical entailment (leaving such options as exact models are to be used for entailment open ).
  • XML serialization framework. This framework defines the general principles that logic dialects are to use in specifying their concrete XML-based syntaxes. For each dialect, its concrete XML syntax is a derivative of the dialect's presentation syntax.
rif fld
Гибкость RIF-FLD

Каркас RIF содержит набор конструкций, достаточных для :

  • Формирования диалектов с различной семантикой, включая хорошо обоснованную семантику и стабильную семантику
  • Введения правил, имеющих широкий диапазон представлений – от Хорновских правил до универсальных правил с произвольными формулами в голове (таким образом, например, становятся представимыми как правила дизъюнктивного Datalog’а, так и GLAV взгляды)
  • Выбора трактовки предположения об уникальности имен (в логическом программировании синтаксически разные базовые термы обозначают разные объекты, а в дескриптивных логиках это не так)
other known rif d ialect s not yet standards
Other known RIF dialects (not yet standards)
  • RIF Core Answer Set Programming Dialect CASPD is intended to capture the paradigm of declarative logic programming that is based on the answer set semantics (it is also known as the stable model semantics when applied to a subset of the language). The ASP paradigm is especially useful as a way of specifying and solving NP-complete problems. RIF-CASPD is defined as a specialization of the RIF framework for logic-based dialect
  • RIF Core Logic Programming Dialect Based on the Well-founded Semantics-CLPWD is intended to capture the paradigm of declarative logic programming that is based on the WFS. RIF-CLPWD is defined as a specialization of the RIF framework for logic-based dialect
  • Uncertainty Rule Dialect (RIF-URD) to support a direct representation of uncertain knowledge. A fuzzy extension to Description Logic Programs (DLP), called Fuzzy DLP, and discuss its mapping to RIF. Such a formalism combines DL with LP, as in DLP and supports uncertain knowledge representation
  • Default logic based dialect is planned in frame of the SILK project
rules and owl interoperability
Rules and OWL Interoperability
  • A “logical framework" is required that will be sitting above the OWL and rules stack and will enable inferences performed by OWL to be used by the rules stack, and vice versa
  • The basic idea is that rules and OWL will view each other as “black boxes" with well-defined interfaces defined through exported predicates. OWL-based ontologies will export some of their classes and properties, while rule-based knowledge bases will export some of the predicates that they define. Each type of the knowledge base will be able to refer to the predicates defined in the other knowledge bases and treat them extensionally, as collections of facts.
  • Thus, the hybrid architecture offers a way to combine expressive classes of nonmonotonic rule bases with OWL-based ontologies
hybrid approach
Hybrid approach
  • Ontologies are assumed to provide commonly shared conceptualization of a domain. There may be different application-specific rule programs for different applications in the domain.
  • Rules would not define new classes or properties of the ontology, but rather some application-specific relations, while referring in the bodies to classes and properties defined by a given ontology.
  • This is similar to defining views in a given relational database. Such an

approach is called hybrid.

  • The ontology remains unchanged and rules are built on top of ontologies. This makes possible integration of existing rule reasoner with existing ontology reasoner for reasoning in the hybrid language, rather than developing a new reasoner from scratch.
  • LP rule language R and an ontology language S based on a description

logic.A hybrid rule over R and S is a rule of the form

H <- B1 & . . . & Bm & Q1 & . . . & Qn

where, m, n >= 0, H, Bi are literals, Qj are queries in query language QS

slide72
Выводы
  • Принятие стандарта RIF W3C - важное событие
  • Впервые работа по унификации языков выполняется как задача крупного консорциума. Осознание необходимости подобной работы таким разнородным сообществом как W3C уже событие
  • В результате работы RIF WG можно рассматривать программы на правилах как особый вид ИР, который может быть использован в различных средах интеграции и интероперабельного использования ИР (например, в средах предметных посредников).
  • Благодаря высокому уровню абстракции и декларативности программ на правилах, становится практически достижимой точная спецификация поведения в концептуальных моделях ограниченная пока спецификацией пред- и пост-условий. В частности, применение различных моделей логических рассуждений становится реально возможным при решении задач с использованием множества неоднородных распределенных информационных ресурсов.
slide73
Выводы (2)
  • Предложен тщательно обоснованный и формализованный подход к созданию семейства диалектов языков на правилах, позволяющих однородно представить многообразие существующих языков.
  • Для языков ЛП определен каркас, позволяющий конструировать различные диалекты, на основе которых можно создавать взаимные сохраняющие семантику отображения адекватных диалекту существующих языков ЛП в диалект.
  • Такие отображения являются необходимой предпосылкой обеспечения интероперабельности и повторного использования логических программ. Новый диалект создается как расширение существующих диалектов, управляемое каркасом.
  • Стандарт RIF будет стимулировать развитие исследований по созданию сохраняющих семантику, конформных отображений языков на правилах
language extensions
Language extensions
  • Let L1 ⊆ L2 be two logic languages and suppose their semantics are defined using the entailment relations ⊨1 and ⊨2. L2 is said to be an extension of L1 if for any pair of formulas φ, ψ ϵ L1, the entailment φ ⊨1 ψ holds iff φ ⊨2 ψ holds.
  • In case of a rules language, the set of formulas that can be used as premises is not the same as the formulas that can be used as consequents. Therefore, we should assume that L1 = Premises1 ⋃ Consequents1 and L2 = Premises2 ⋃ Consequents2. In addition, as in the case of DLP and Datalog, L1 may not actually be a subset of L2. Instead, it may be embedded in L2 under a 1-1 transformation, ι. In our notation, this is expressed as ι(Premises1) ⊆ Premises2 and ι(Consequents1) ⊆ Consequents2.
  • We can now say that L2 extends L1 under the embedding ι if for every pair of formulas, φ ϵ Premises1 and ψ ϵ Consequents1, the entailment φ ⊨1 ψ holds iff ι(φ) ⊨2 ι(ψ) holds.
stable model and answer set programming asp
Stable Model and Answer Set Programming (ASP)
  • In default logic a rule includes, besides its premises and conclusion, a list of formulas called justifications. A default can be used to derive its conclusion under the assumption that its justifications are consistent. It is possible to treat negated atoms in the bodies of rules (under stable model semantics) as justifications
  •  The autoepistemic logic uses a modal operator to distinguish between what is true and what is believed. not p in the body of a rule can be read (V.Lifschitz) as "p is not believed"(rule with negation is a formula of autoepistemic logic).
  • Distingushing ability to express defaults: assertions of the form “Elements of a class C normally satisfy property P”. Learning of defaults, exception to these defaults and the way of using this information to draw the reasonable conclusions about the world be supported by stable model and ASP. It allows to express disjunction and classical negation  
  • ASP allows also to express the causal effects of actions (“statement F becomes true as a result of performing an action alpha”), statements expressing a lack of information (“it is not known if statement P is true or false”), various CWA assumptions (“statements not entailed by the knowledge base are false”).
slide78
Системы программирования множества ответов (ASP)
  • The search algorithms used in design of many ASP solvers are enhancements of the procedure similar to efficient SAT solvers. Unlike SLDNF in Prolog, such algorithms always terminate.
  • System LPARSE was originally created as a front-end for the answer set solver SMODELS, and it is now used in the same way in most other answer set solvers. (System DLV is an exception; syntax of ASP for DLV is different)
  • Constraints (rules with empty head) and choice rules are supported. The effect of adding a constraint to a program is to eliminate some of its stable models. 

{s,t} :- p. 

Intuitively, the choice rule means: if p is included in the stable model then choose arbitrarily which of the atoms s, t to include.

  • ASP programs can include CWA rules for some of its predicates and leave the other predicates in the realm of OWA
rif wg initial plans
RIF WG initial plans
  • The W3C RIF WG is chartered to develop an exchange format for rules that should enable rules to be translated between different rule languages and, thus, to be used in different rule systems. Planned in two phases:
  • Phase I focuses essentially on Horn rules for a core rule interchange format.
  • For Phase II, the charter just gives starting points for possible extensions. For example, the core format might be extended in the direction of first-order rules, (possibly non-monotonic) logic programming rules, and particularly ECA and production rules.
  • The charter also emphasizes compatibility with Web and Semantic Web technologies such as XML, RDF, SPARQL, and OWL.
  • It is not the goal of RIF to provide a one-for-all rule language which can cover all of these features. Distinct features of different rule systems are often simply incompatible. Rather, the concept of RIF dialects will enable the exchange of rules within common fragments or variable feature sets between various parties in a modular fashion.
importance of rif for w3c and e science
Importance of RIF for W3C and e-science

Creating a generally accepted RIF is by no means a trivial task:

  • different kinds of rules: deduction rules, normative rules, production rules, reactive rules, etc.
  • within the same category of rules, systems use different (often incompatible) semantics and syntaxes
  • existing Semantic Web standards, such as RDF and OWL, show incompatibilities with many kinds of rule languages

The intersection of DLs and Rules is of interest for several reasons.

  • such an intersection could form the common basis for and promote interoperability between DL and Rules based ontology languages;
  • understanding the expressive intersection of these two KRs may help to understand the expressive combination/union of the two KRs;
  • ontologies that are within this intersection may be able to use rules engines to provide scalable reasoning services.
rdf s owl and rules
RDF(S), OWL and rules

It is not easy to combine OWL with most rule-based formalisms

  • OWL allows disjunctive and existential information (most rule-based systems do not)

2) OWL is based on FOL, but many rule-based formalisms support so-called default reasoning which is not first-order.

RDF (and RDFS) allows expressing knowledge in the Semantic Web but does not provide ways of extracting new knowledge from the asserted one.

Rule support in RDF(S) is already a practical reality.

syntactic framework
Syntactic framework
  • Constants and variables. These terms are common to most logic languages.
  • Positional terms. These terms are commonly used in first-order logic.
  • Terms with named arguments. Terms with named arguments generalize the notion of rows in relational tables, where column headings correspond to argument names.
  • Lists. These terms correspond to lists in logic programming
  • Frames. A frame term represents an assertion about an object and its properties. These terms correspond to molecules of F-logic. There is syntactic similarity between terms with named arguments and frames
  • Classification. These terms are used to define the subclass and class membership relationships. There are two kinds of classification terms: membership terms and subclass terms (borrowed from F-logic)
  • Equality. These terms are used to equate other terms.
  • Formula terms. These terms are the ones for which truth values are defined by the RIF semantic framework. Most dialects would treat such terms in a special way and will impose various restrictions on their contexts. Some advanced dialects, however, will have fewer such restrictions, which will make it possible to reify formulas and manipulate them as objects.
syntactic framework 2
Syntactic framework (2)
  • External. These terms are used to represent built-ins and external data sources that are treated as "black boxes."
  • Aggregation. These are the terms that are used to represent aggregation functions over sets.
  • Remote. These terms are used to represent queries to RIF documents that are not part of the RIF document that contains these terms.
  • Terms are then used to define several types of RIF-FLD formulas. RIF dialects can choose to permit all or some of the aforesaid categories of terms. In addition, RIF-FLD introduces extension points, one of which allows the introduction of new kinds of terms. An extension point is a keyword that is not a syntactic construct per se, but a placeholder that is supposed to be replaced by specific syntactic constructs of an appropriate kind. RIF-FLD defines several types of extension points: symbols (NEWSYMBOL), connectives (NEWCONNECTIVE), quantifiers (NEWQUANTIFIER), aggregate functions (NEWAGGRFUNC), and terms (NEWTERM).
specialization mechanisms of syntactic framework
Specialization mechanisms of syntactic framework
  • Extension points RIF-FLD introduces extension points a placeholder to be replaced by specific syntactic constructs of an appropriate kind (symbols (NEWSYMBOL), connectives (NEWCONNECTIVE), quantifiers (NEWQUANTIFIER), aggregate functions (NEWAGGRFUNC), and terms (NEWTERM))
  • Symbol spaces. Symbol spaces partition the set of non-logical symbols that correspond to individual constants, predicates, and functions, and each partition is then given its own semantics. A symbol space has an identifier and a lexical space, which defines the "shape" of the symbols in that symbol space.
  • Signatures.Signatures determine which terms and formulas are well-formed. They constitute a generalization of the notion of sorts in classical first-order logic. In this way, it is possible to control which symbols are used for predicates and which for functions, where variables can occur, and so on.
  • Restriction. A dialect might impose further restrictions on the form of a particular kind of term or formula. For example, variables or aggregate terms might not be allowed in certain places.
semantic framework
Semantic framework
  • Defines the notion of a semantic structure (interpretation) to interpret formulas and to define logical entailment. Themechanisms of specializationinclude:
  • Set of truth values. RIF-FLD is designed to accommodate dialects that support reasoning with inconsistent and uncertain information. Most of the respective logics are multi-valued. RIF-FLD postulates that there is a set of truth values, TV, which includes the values t (true) and f (false) and possibly others.
  • Semantic structures determine how the different symbols in the alphabet of a dialect are interpreted and how truth values are assigned to formulas.
  • DatatypesA symbol space whose symbols have a fixed interpretation in any semantic structure is called a datatype.
  • Entailment. This notion is fundamental to logic-based dialects. Entailment is the main mechanism underlying query answering in Databases, Logic Programming, and the various reasoning tasks in Description Logics. A set of formulas G logically entails another formula g if for every semantic structure I in some set S, if G is true in I then g is also true in I. Almost all logics define entailment this way. The difference lies in which set S they use.
rif homogeneous vs hybrid rules ontology integration
RIF: Homogeneous vs Hybrid Rules/Ontology Integration
  • In the hybrid approach there is a strict separation between the ordinary predicates, which are basic rule predicates and ontology predicates, which are only used as constraints in rule antecedents. Reasoning is done by interfacing existing rule reasoner with existing ontology reasoner.
  • In the homogeneous approach both ontologies and rules are embedded in a logical language L without making a priori distinction between the rule predicates and the ontology predicates. In this way a subset R of L is defined. For reasoning in R either a general reasoner of L can be reused, or a specialized reasoner for R is to be constructed.
entailment in rdf
Entailment in RDF
  • A RDF graph corresponds to an existentially closed conjunction of binary atomic formulae. It is not possible to express negations or disjunctions of formulae.

The RDF Semantics specifies four distinct forms of entailment:

  • Simple entailment: can be understood as a subgraph-matching problem, which is known to be decidable but a NP-complete problem
  • RDF entailment is based on a notion of rdf:Property, that declares the resources of RDF vocabulary which are properties. The other difference to simple RDF entailment is the recognition of syntactically correct rdf:XMLLiterals
  • RDFS entailment the full RDF and RDFS vocabularies can be used, including classes. This allows to deduce a lot of axiomatic triples from any given RDF-graph.
  • Datatype entailment RDFS entailment is extended for supporting other typed literals, with emphasis in several XML Schema Datatypes like decimals, integers, dates, and strings.
rdf and owl semantics for rif
RDF and OWL Semantics for RIF
  • OWL 2 specifies two different variants of the language, each having its own semantics, namely OWL 2 DL [OWL2-Syntax] (called simply OWL 2 in the specification) - DL semantics, and OWL 2 Full [OWL2-RDF-Based-Semantics] – RDFS semantics
  • A RIF document with RDF graphs is viewed as a combination of a document and a number of graphs and ontologies. The conditions under which the combination is satisfiable (i.e., consistent),as well as the entailments (i.e., logical consequences) of the combination are defined in the OWL/RIF compatibility specification. The interaction between RIF and RDF/OWL is realized by connecting the model theory of RIF [RIF-BLD] with the model theories of RDF [RDF-Semantics] and OWL [OWL2-Semantics], respectively.
  • The RDF semantics specification [RDF-Semantics] defines four normative notions of entailment for RDF graphs: Simple, RDF, RDFS, and Datatype entailment. OWL 2 specifies two different semantics, with corresponding notions of entailment: the direct semantics [OWL2-Semantics], which specifies OWL 2 DL entailment, and the RDF-based semantics [OWL2-RDF-Based-Semantics], which specifies OWL 2 Full entailment. All six variants are taken into account (OWL/RIF compatibility doc)
owl rif compatibility issues
OWL/RIF Compatibility Issues
  • In the Full variant, classes and properties are interpreted as objects in the domain of interpretation. In the DL variant, classes and properties are directly interpreted as subsets of, respectively binary relations over the domain. Defining RIF-OWL DL compatibility as an extension of RIF-RDF compatibility would define a correspondence between OWL 2 DL statements and RIF frame formulas.
  • To ensure that the RIF-OWL DL combination is faithful to the OWL 2 DL semantics and to enable using the same, or similar, RIF rules in combinations with both OWL 2 DL and RDF/OWL 2 Full, the interpretation of frame formulas s[p -> o] in RIF-OWL DL combinations is slightly different from their interpretation in RIF and syntactical restrictions are imposed on the use of variables and function terms in frame formulas
scenarios of use rif together with rdf data or rdfs owl ontologies
Scenarios of use RIF together with RDF data or RDFS/OWL ontologies
  • An interchange partnerA has a rules language that is RDF/OWL-aware. A sends its rules using RIF, possibly with references to the appropriate RDF graph(s), to partner B. B receives the rules and retrieves the referenced RDF graph(s). The rules are translated to the internal rules language of B and are processed, together with the RDF graphs, using the RDF/OWL-aware rule engine of B.
  • The publication of RIF rules as a special kind of interchange: one to many. there may be several consumers that retrieve the RIF rules and RDF graphs from the Web and manipulate them similarly to a partner B in scenario 1.
  • Interchange partner A has a rules language that extends OWL.A splits its ontology+rules description into a separate OWL ontology and a RIF document, publishes the OWL ontology, and sends (or publishes) the RIF document. A consumer of the rules retrieves the OWL ontology and translates the ontology and document into a combined ontology+rules description in its own rule extension of OWL.
rif core dialect
RIF Core Dialect
  • RIF-Core corresponds to the language of definite Horn rules without function symbols (often called 'Datalog'). RIF-Core also is a language of production rules where conclusions are interpreted as assert actions.
  • RIF-Core has a number of Datalog extensions to support features such as objects and frames as in F-logic, internationalized resource identifiers (or IRIs) as identifiers for concepts, and XML Schema datatypes
  • RIF-Core is not the maximal common subset of RIF-BLD and RIF-PRD.
syntax restrictions of the core w r t rif bld
Syntax restrictions of the Core w.r.t. RIF-BLD
  • The alphabet of the presentation language of RIF-Core is the alphabet of the RIF-BLD presentation language with the exclusion of the symbol ## (subclass) and the set of symbols ArgNames (used for named-argument uniterms).
  • The Terms of RIF-Core are the terms of RIF-BLD with the exclusion of subclass terms and of terms with named arguments. In RIF-Core there are only closed ground lists.
  • A closed ground list has the form List(t1 ... m), where m≥0 and t1, ..., tm are ground terms (no tail and no variables are allowed).
syntax restrictions of the core formulae
Syntax restrictions of the Core formulae

The Formulas of RIF-Core are the formulas of RIF-BLD with the following restrictions.

  • Subterms that occur inside atomic formulas can be variables, constants, ground list, or external positional terms. This implies that RIF-Core only allows external function applications.
  • Equality terms and class membership terms cannot occur in rule conclusions -- they are allowed only in rule premises.
  • Terms with named arguments and subclass terms are excluded from RIF-Core.
  • A syntactically correct RIF-Core formula that passes the well-formedness test for RIF-BLD is also a well-formed RIF-Core formula.
  • Recall that RIF-Core does not allow uninterpreted (i.e., non-external) function symbols. Therefore no symbol in RIF-Core can occur in the context of an (uninterpreted) function symbol.
rif basic logic dialect
RIF Basic Logic Dialect
  • RIF-BLD is from a class of languages based on definite Horn rules with equality and a standard first-order semantics..
  • Syntactically, RIF-BLD has a number of extensions to support features such as objects and frames as in F-logic, internationalized resource identifiers ( IRIs) as identifiers for concepts, and XML Schema datatypes.
  • RIF RDF and OWL Compatibility defines semantics for the integrated RIF-BLD/RDF and RIF-BLD/OWL languages.
  • Unlike ISO Common Logic (CL), RIF-BLD was designed to be a simple dialect with limited expressiveness that lies within the intersection of first-order and logic-programming systems, it does not support negation.
  • The RIF framework for logic dialects also includes a variety of rule languages based on non-monotonic theories
  • For rule interchange between CL and RIF dialects, it is expected that partial RIF-CL mappings will be defined.
rule language
Rule Language

Document  ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'

Base  ::= 'Base' '(' ANGLEBRACKIRI ')'

Prefix  ::= 'Prefix' '(' Name ANGLEBRACKIRI ')'

Import  ::= IRIMETA? 'Import' '(' LOCATOR PROFILE? ')'

Group  ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'

RULE  ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE

CLAUSE  ::= Implies | ATOMIC

Implies  ::= IRIMETA? (ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA

LOCATOR  ::= ANGLEBRACKIRI

PROFILE  ::= ANGLEBRACKIRI

Annotations:

IRIMETA  ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'

condition language
Condition Language

FORMULA  ::= IRIMETA? 'And' '(' FORMULA* ')' |

IRIMETA? 'Or' '(' FORMULA* ')' |

IRIMETA? 'Exists' Var+ '(' FORMULA ')' | ATOMIC |

IRIMETA? 'External' '(' Atom ')'

ATOMIC  ::= IRIMETA? (Atom | Equal | Member | Subclass | Frame)

Atom  ::= UNITERM

UNITERM  ::= Const '(' (TERM* | (Name '->' TERM)*) ')'

Equal  ::= TERM '=' TERM

Member  ::= TERM '#' TERM

Subclass  ::= TERM '##' TERM

Frame  ::= TERM '[' (TERM '->' TERM)* ']'

TERM  ::= IRIMETA? (Const | Var | Expr | List | 'External' '(' Expr ')')

Expr  ::= UNITERM

List  ::= 'List' '(' TERM* ')' | 'List' '(' TERM+ '|' TERM ')'

Const  ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT

Var  ::= '?' Name

Name  ::= NCName

SYMSPACE  ::= ANGLEBRACKIRI | CURIE

more details
More details
  • A frame term is a term composed of an object identifier and a collection of attribute-value pairs.
  • The term External(Atom) is a call to an externally defined predicate. Likewise, External(Expr) is a call to an externally defined function.
  • Conditions are composed of atoms, expressions, equalities with lists, frames, and existentials.
  • In frame formulas, variables are shown in the positions of object identifiers, object properties, and property values,
  • prefix:suffix is understood as a shorthand for an IRI obtained by concatenation of the prefix definition and suffix.
constant symbols
Constant symbols

The set of all constant symbols, Const, is partitioned into the following subsets:

  • A subset of individuals. .
  • A subset of plain (i.e., non-external) function symbols.
  • A subset for external function symbols.
  • A subset of plain predicate symbols.
  • A subset for external predicate symbols
examples
Examples

Prefix(bks <http://example.com/books#>)

Prefix(auth <http://example.com/authors#>)

Prefix(cpt <http://example.com/concepts#>)

  • Positional terms:

cpt:book(auth:rifwgbks:LeRif)

Exists ?X (cpt:book(?X bks:LeRif))

  • Terms with named arguments:

cpt:book(cpt:author->auth:rifwgcpt:title->bks:LeRif)

Exists ?X (cpt:book(cpt:author->?X cpt:title->bks:LeRif))

  • Equalities with list terms:

 ?L = List(?X ?Y ?X)

List(?Head | ?Tail) = List("a"^^rif:local ?Y "c"^^rif:local)

examples frames
Examples: Frames

bks:wd1[cpt:author->auth:rifwg cpt:title->bks:LeRif]

Exists ?X (bks:wd2[cpt:author->?X cpt:title->bks:LeRif])

Exists ?X (And (bks:wd2#cpt:book bks:wd2[cpt:author->?X cpt:title->bks:LeRif]))

Exists ?I ?X (?I[cpt:author->?X cpt:title->bks:LeRif])

Exists ?I ?X (And (?I#cpt:book ?I[cpt:author->?X cpt:title->bks:LeRif]))

Exists ?S (bks:wd2[cpt:author->auth:rifwg ?S->bks:LeRif])

Exists ?X ?S (bks:wd2[cpt:author->?X ?S->bks:LeRif])

Exists ?I ?X ?S (And (?I#cpt:book  ?I[author->?X ?S->bks:LeRif]))

example rules
Example: Rules
  • If an item is perishable and it is delivered to John more than 10 days after the scheduled delivery date then the item will be rejected by him.
  • Document( Prefix(ppl <http://example.com/people#>) Prefix(cpt <http://example.com/concepts#>) Prefix(dc <http://purl.org/dc/terms/>)
  • Prefix(func <http://www.w3.org/2007/rif-builtin-function#>) Prefix(pred <http://www.w3.org/2007/rif-builtin-predicate#>)

Prefix(xs <http://www.w3.org/2001/XMLSchema#>) (* "http://sample.org"^^rif:iri _pd[dc:publisher -> "http://www.w3.org/"^^rif:iri dc:date -> "2008-04-04"^^xs:date] *)

Group (

Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays ( cpt:reject(ppl:John ?item) :-

And(cpt:perishable(?item) cpt:delivered(?item ?deliverydate ppl:John) cpt:scheduled(?item ?scheduledate) ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate))  ?diffdays = External(func:days-from-duration(?diffduration)) External(pred:numeric-greater-than(?diffdays 10))) )

Forall ?item ( cpt:reject(ppl:Fred ?item) :- cpt:unsolicited(?item) ) )

rif bld semantics
RIF-BLD Semantics
  • A semantic structure, I, is a tuple of the form <TV, DTS, D, Dind, Dfunc, IC, IV, IF, INF, Ilist, Itail, Iframe, Isub, Iisa, I=, Iexternal, Itruth>. Here D is a non-empty set of elements called the domain of I, and Dind, Dfunc are nonempty subsets of D. Dind is used to interpret the elements of Const that occur as individuals and Dfunc is used to interpret the elements of Const that occur in the context of function symbols. As before, Const denotes the set of all constant symbols and Var the set of all variable symbols. DTS denotes a set of identifiers for datatypes

Ilist and Itail are used to interpret lists. They are mappings of the following form:

Ilist : Dind* → Dind

Itail : Dind+× Dind → Dind

rif bld semantics 2
RIF-BLD Semantics (2)
  • Iframe maps Dind to total functions of the form SetOfFiniteBags (Dind × Dind) → D.
  • This mapping interprets frame terms. An argument, d ∈ Dind, to Iframe represents an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs for d.
  • Isub gives meaning to the subclass relationship. It is a mapping of the form Dind × Dind → D. Iisa gives meaning to class membership. It is a mapping of the form Dind × Dind → D
rif bld semantics 3
RIF-BLD Semantics (3)

Some of truth-valued functions:

  • Atomic formulas with named arguments:

TValI(p(s1->v1 ... sk->vk)) = Itruth(I(p(s1->v1 ... sk->vk))). 

  • Equality: TValI(x = y) = Itruth(I(x = y)).

To ensure that equality has precisely the expected properties, it is required that: Itruth(I(x = y)) = t if I(x) = I(y) and that Itruth(I(x = y)) = f otherwise.

TValI(x = y) = t if and only if I(x) = I(y).

  • Rule implication:

TValI(conclusion :- condition) = t, if either TValI(conclusion)=t or

TValI(condition)=f.

TValI(conclusion :- condition) = f   otherwise.

semantics 4
Semantics (4)
  • Truth value for a Groups of rules:

If Γ is a group formula of the form Group(φ1 ... φn) then

TValI(Γ) = t if and only if TValI(φ1) = t, ..., TValI(φn) = t.

TValI(Γ) = f   otherwise.

This means that a group of rules is treated as a conjunction.

  • Logivcal entailment

A multi-structure Î is a model of a formula, φ, written as Π|= φ, iff TValÎ(φ) = t (Logical entailment). Let φ and ψ be (document or non-document) formulas. We say that φ entailsψ, written as φ |= ψ, if and only if for every multi-structure, Î, Π|= φ implies Π|= ψ. 

comment on fixpoint semantics
Comment on Fixpoint Semantics
  • Horn programs have the model-intersection property. Thus, the intersection of all models of a Horn program, P, is also a model of P. This is the least model of P
  • The least fixpoint of P coincides with the least model of P
  • PRZYMUSINSKI. T. C. 1989. Every logic program has a natural stratification and an iterated least fixed point model. In Proceedings of the 8th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (Philadelphia, Pa,, Mar. 29-31). ACM, New York, pp. 11-21
external schemas
External Schemas
  • External schemasserve as templates for externally defined terms. They are designed to also accommodate the ideas of procedural attachments and querying of external data sources.(Schema for external term).
  • An external schema is a statement of the form (?X1 ... ?Xn; τ) where τ is a positional or a named-argument term.

?X1 ... ?Xn is a list of all distinct variables that occur in τ

  • The names of the variables in an external schema are immaterial, but their order is important. For instance, (?X ?Y;  ?X[foo->?Y]) and (?V ?W;  ?V[foo->?W]) are considered to be indistinguishable,

but (?X ?Y;  ?X[foo->?Y]) and (?Y ?X;  ?X[foo->?Y]) are different schemas.

external schemas 2
External Schemas (2)
  • A term t is an instantiation of an external schema (?X1 ... ?Xn; τ) iff t can be obtained from τ by a simultaneous substitution ?X1/s1 ... ?Xn/sn of the variables ?X1 ... ?Xn with terms s1 ... sn, respectively. Some of the terms si can be variables themselves. For example, ?Z[foo->f(a ?P)] is an instantiation of (?X ?Y; ?X[foo->?Y]) by the substitution ?X/?Z  ?Y/f(a ?P).   
  • The intuition behind the notion of an external schema, such as (?X ?Y;  ?X["foo"^^xs:string->?Y]) or (?V;  "pred:isTime"^^rif:iri(?V)), is that ?X["foo"^^xs:string->?Y] or "pred:isTime"^^rif:iri(?V) are invocation patterns for querying external sources, and instantiations of those schemas correspond to concrete invocations.
  • Thus, External("http://foo.bar.com"^^rif:iri["foo"^^xs:string->"123"^^xs:integer]) and External("pred:isTime"^^rif:iri("22:33:44"^^xs:time) are examples of invocations of external terms -- one querying an external source and another invoking a built-in.