• PRdialect
• Overview

Introduction

• *** General introduction to be developed. ***

Overview of RIF production rule dialect

To be updated following restructuring of the draft

The RIF production rule dialect (RIF-PRD) follows the above general model for production rules and rulesets closely. As a consequence, RIF-PRD specifies two sublanguages:

• the RIF-PRD condition language, which extends the RIF-Core ([ RIF-Core]) [ condition language], determines what can appear in the condition of a rule supported by RIF-PRD;
• the RIF-PRD action language, which extends the RIF-PRD condition language, determines what can appear in the action part of a rule supported by RIF-PRD.

RIF-PRD extends these sublanguages to specify the interchange format for production rules and rulesets.

RIF-PRD as an interchange format for production rules

• *** Overview of PRD and its semantics to be developed ***

RIF-PRD as a Web language

To make RIF dialects suitable as Web languages, RIF supports XML Schema primitive data types and some other data types. In addition, RIF promotes the use of Internationalized Resource Identifiers (or IRIs) RFC 3987 to refer to individuals, predicates, and functions.

Compatibility with other RIF dialects

To ensure compatibility with RIF Core dialect ([ RIF-Core]) and its extensions, the RIF production rule language (RIF-PRD) does not draw a sharp boundary between the symbols used to denote individuals from symbols used as names for functions or predicates. Instead, all constant, predicate, and function symbols are drawn from the same universal set. The framework for logic-based RIF dialects RIF-FLD explains how RIF logic dialects control the contexts in which the different symbols can occur by attaching signatures to these symbols.

• *** "Individual"? "Object"? The intention is to make it clear that constants may stand for something more complex that a single, simple value, and I would fear that using "object" might be too specific, e.g. what about records, etc? Anyway, whatever terminology we use must be consistent and defined. ***

In RIF-PRD, individuals, constants, functions and predicates behave as if they were drawn from different sets and signatures are not part of the RIF-PRD language.

• *** Or should we just drop that section altogether? ***

Syntaxes

In this document we will introduce two related but distinct representations for RIF-PRD components:

• Structural diagrams. The overall structure of the syntax used in RIF-PRD will be presented as UML diagrams. The diagrams are used to introduce RIF-PRD syntactic classes and to show at a glance how they relate to each others. Three kinds of syntactic components are used to specify RIF-PRD:

  • Abstract classes are defined only by their subclasses: they not visible in the XML markup and can be thought of as extension points. In this document, abstract constructs will be denoted with all-uppercase names;

  • Concrete classes have a concrete definition and they are associated with specific XML markup. In this document, concrete constructs will be denoted with CamelCase names with leading capital letter;

  • Properties, or roles, define how two classes relate to each other. They have concrete definitions and are associated with specific XML markup. In this document, properties will be denoted with camelCase names with leading smallcase letter;

  Shall PRD have structural diagrams? Only if BLD has them? Only of Core has them? Even if none of them has them? In no case whatsoever?... ***

• XML syntax. This syntax is the normative XML serialization of RIF-PRD. The key features of this syntax are derived from the structural diagrams, but some aspects related to rule exchange do not have counterparts in the diagrams;

• Presentation syntax. A human-friendly presentation syntax is specified non-normatively.

Overview of this document

TBD

BNF pseudo-schema

The XML syntax is specified for each component as a pseudo-schemas, before the description of the component. The pseudo-schemas use BNF-style conventions for attributes and elements: "?" denotes optionality (i.e. zero or one occurrences), "*" denotes zero or more occurrences, "+" one or more occurrences, "[" and "]" are used to form groups, and "|" represents choice. Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema. Elements are conventionally assigned a value which is the name of the syntactic class of their content, as defined in the normative schema.

<!-- sample pseudo-schema -->
    <defined_element
          required_attribute_of_type_string="xs:string"
          optional_attribute_of_type_int="xs:int"? >
      <required_element />
      <optional_element />?
      <one_or_more_of_these_elements />+
      [ <choice_1 /> | <choice_2 /> ]*

    </defined_element>

Namespaces

Throughout this document, the xsd: prefix stands for the XML Schema namespace URI http://www.w3.org/2001/XMLSchema#, the rdf: prefix stands for http://www.w3.org/1999/02/22-rdf-syntax-ns#, and rif: stands for the URI of the RIF namespace, http://www.w3.org/2007/rif#. Syntax such as xsd:string should be understood as a compact uri -- a macro that expands to a concatenation of the character sequence denoted by the prefix xsd and the string string. In the next version of this document we intend to introduce a syntax for defining prefixes for compact URIs.

• *** Namespace for RIF-PRD constructs... ***