RIF: общая характеристика - Рабочая группа симпозиума

Анализ мотивации, целей и
подходов проекта унификации
языков на правилах RIF
Калиниченко Л.А., Ступников С.А.
(ИПИ РАН)
Симпозиум «Онтологическое моделирование»,
КФУ, 11-12 Октября 2010 г.
План рассмотрения
• Унификация языков, интеграция информационных ресурсов,
интероперабельность
• Цели проекта RIF
• Языки на правилах и их применения: краткий исторический экскурс
• Логические модели рассуждений
• Семантики логических программ
• Языки и системы ЛП, оказавшие существенное влияние на RIF
• Примеры использования RIF и системы ЛП в области интересов группы RIF
WG
• Требования к RIF
• Обзор основных решений RIF
• Выводы
Унификация языков,
интеграция информационных
ресурсов, интероперабельность
Унификация языков, интероперабельность
информационных ресурсов
• Требуют унификации: языки реляционных и объектных баз данных,
онтологического моделирования, представления слабо
структурированных, графовых, мультимедийных данных,
представления баз знаний, логического программирования,
дедуктивные языки запросов к базам данных, спецификации потоков
работ, спецификации интерфейсов программных ИР, языки со
специализированной семантикой (например, для выражения
темпоральных, пространственных моделей), языки для определения
нечетких, вероятностных представлений, языки концептуального
моделирования и метамодели, и многие другие.
• Примеры расширяемых унифицирующих языков – СИНТЕЗ
• Программы на правилах – новый вид ИР , унификация ЯП
• Цель RIF: создание расширяемого унифицированного семейства
языков на правилах
• Применение подхода должно быть общим, не ограничиваться Вебом
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)
Цели проекта RIF
Концепция RIF
• Рабочая группа W3C RIF WG: с 2005 г. Задача:
– Обеспечить использование потенциала, накопленного при создании и
использовании различных языков и систем на правилах
– Совместимость с RDF и OWL
• Цель: создание унифицированных диалектов на правилах, в которые
существующие языки на правилах могли быть отображены с
сохранением семантики , позволяя правила, созданные в рамках
некоторого приложения, публиковать, использовать совместно с другими
правилами, повторно использовать в других приложениях и других
машинах
• Унифицированный язык представляется как семейство диалектов,
которые имеют общее ядро (корневой диалект) и совокупность
расширяющих его диалектов
• Для полновесного включения каждого языка на правилах в совокупность
интероперабельных языков достаточно снабдить соответствующую
систему программирования двумя сохраняющими семантику
преобразователями – из собственного языка в диалект (роль
поставщика) и из диалекта в собственный язык (роль пользователя)
Принятие стандарта
• 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
Языки на правилах и их
применения: краткий
исторический экскурс
Программы на правилах, классы
применений
• 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
Применение логики для представления
знаний и решения задач
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)
Дедуктивные базы данных
• 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).
Cистемы дедуктивных баз данных (1)
Системы дедуктивных баз данных (2)
Логические модели
рассуждений
Логические модели рассуждений
Примеры различных видов (моделей) немонотонных рассуждений:
• Абдуктивные рассуждения:вид автоматизированного
правдоподобного рассуждения
• Рассуждения на основе умолчания: имеется возможность отказа от
предположения умолчания, когда оказывается, что оно неверно
• Отрицание как неудача: основано на предположении о замкнутости
мира
• Логика очерчивания (circumscription): действуют предположения
здравого смысла, пока нет других указаний
• Автоэпистемическая логика: представление знаний о знаниях и
рассуждения в таком контексте
• Логика отмены заключений: при рассуждениях заключения не
окончательны, они могут быть скорректированы или отменены
• Логика рассуждений с неопределенностью: например, использование
Байесовского формализма в системах правил
• Теории аргументации: основана на искусстве ведения дебатов,
убеждения, применяя логические рассуждения
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
• 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 NAFliterals 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 (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.
• Backward reasoning, where an atomic query is matched/unified with the
head of a rule and replaced by the respective instance of the body
• Forward reasoning, 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.
Хорновские правила
• 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
Overlaps among Different Logics
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
• 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)
• 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
• 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
• 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
Хорошо обоснованная семантика (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.
Хорошо обоснованная и стабильная
семантики
• 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)
Фреймовая логика и язык
метапрограммирования (F-Logic)
• F-logic combines the advantages of conceptual modeling with objectoriented, 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
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-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-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’].
Примеры запросов
• ?- 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.
Class Hierarchy
Реификация
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
• 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
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-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 Flogic is only an approximation: john[has! #:(book or bicycle)] (# - Skolem
constant)
Примеры использования RIF и
системы ЛП в области
интересов группы 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 (2)
Системы на правилах, отобранные для
анализа и выработки требований к RIF (3)
Категории примеров использования
Список категорий примеров использования выглядит так (ранняя
категоризация 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
Требования к RIF
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.
Общие требования к 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).
Сравнение х-к систем на правилах (Grosof)
Требования, мотивированные примерами
использования (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.
Требования, мотивированные примерами
использования (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.
Обзор основных решений RIF
Решения RIF
• Known rule systems fall into three broad categories: first-order, logicprogramming, 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
• RIF-BLD: The Basic Logic Dialect this 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 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 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
• 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 содержит набор конструкций, достаточных для :
• Формирования диалектов с различной семантикой, включая хорошо
обоснованную семантику и стабильную семантику
• Введения правил, имеющих широкий диапазон представлений – от
Хорновских правил до универсальных правил с произвольными
формулами в голове (таким образом, например, становятся
представимыми как правила дизъюнктивного Datalog’а, так и GLAV
взгляды)
• Выбора трактовки предположения об уникальности имен (в логическом
программировании синтаксически разные базовые термы обозначают
разные объекты, а в дескриптивных логиках это не так)
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
• 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. OWLbased ontologies will export some of their classes and properties, while rulebased 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
•
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
Состояние реализации RIF
Состояние реализации RIF (2)
Выводы
• Принятие стандарта RIF W3C - важное событие
• Впервые работа по унификации языков выполняется как задача
крупного консорциума. Осознание необходимости подобной работы
таким разнородным сообществом как W3C уже событие
• В результате работы RIF WG можно рассматривать программы на
правилах как особый вид ИР, который может быть использован в
различных средах интеграции и интероперабельного использования ИР
(например, в средах предметных посредников).
• Благодаря высокому уровню абстракции и декларативности программ
на правилах, становится практически достижимой точная
спецификация поведения в концептуальных моделях ограниченная
пока спецификацией пред- и пост-условий. В частности,
применение различных моделей логических рассуждений
становится реально возможным при решении задач с использованием
множества неоднородных распределенных информационных ресурсов.
Выводы (2)
• Предложен тщательно обоснованный и формализованный подход к
созданию семейства диалектов языков на правилах, позволяющих
однородно представить многообразие существующих языков.
• Для языков ЛП определен каркас, позволяющий конструировать
различные диалекты, на основе которых можно создавать взаимные
сохраняющие семантику отображения адекватных диалекту
существующих языков ЛП в диалект.
• Такие отображения являются необходимой предпосылкой обеспечения
интероперабельности и повторного использования логических
программ. Новый диалект создается как расширение существующих
диалектов, управляемое каркасом.
• Стандарт RIF будет стимулировать развитие исследований по созданию
сохраняющих семантику, конформных отображений языков на правилах
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.
Post presentation slides
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”).
Системы программирования множества ответов
(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
• 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
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.
1) such an intersection could form the common basis for and promote
interoperability between DL and Rules based ontology languages;
2) understanding the expressive intersection of these two KRs may help to
understand the expressive combination/union of the two KRs;
3) ontologies that are within this intersection may be able to use rules engines to
provide scalable reasoning services.
RDF(S), OWL and rules
It is not easy to combine OWL with most rule-based formalisms
1) 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.
W3C Stack: PRELIMINARY CONSIDERATIONS
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)
•
•
•
•
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
• 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 wellformed. 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
• Defines the notion of a semantic structure (interpretation) to interpret
formulas and to define logical entailment. The mechanisms of specialization
include:
• 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.
• Datatypes A 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
• 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
•
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
•
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-BasedSemantics] – 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 [OWL2Semantics], 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 [OWL2RDF-Based-Semantics], which specifies OWL 2 Full entailment. All six
variants are taken into account (OWL/RIF compatibility doc)
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 RIFOWL 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
1.
2.
3.
An interchange partner A 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 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
• 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
•
•
•
•
•
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-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 RIFBLD/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 firstorder 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
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
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
• 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
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
Prefix(bks <http://example.com/books#>)
Prefix(auth <http://example.com/authors#>)
Prefix(cpt <http://example.com/concepts#>)
•
Positional terms:
cpt:book(auth:rifwg bks:LeRif)
Exists ?X (cpt:book(?X bks:LeRif))
•
Terms with named arguments:
cpt:book(cpt:author->auth:rifwg cpt: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
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
•
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-0404"^^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:subtractdateTimes(?deliverydate ?scheduledate)) ?diffdays = External(func:days-fromduration(?diffduration)) External(pred:numeric-greater-than(?diffdays 10))) )
Forall ?item (
cpt:reject(ppl:Fred ?item) :- cpt:unsolicited(?item) ) )
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)
• 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)
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)
• 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
• 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 serve 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)
• 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.