Proposed Erratum 2

PROPOSE to make it explicit (in DTB) that the xml:lang attribute must be used with value equal langTag for rdf:PlainLitteral constant where the langTag is not empty and that the content of a Const element with type="&rdf;PlainLitteral" is either the data value if the xml:lang attribute is not present, or the first element in the data value pair if the xml:lang attribute is present.

We have the same pb with the items role sub-element in List. PRD says explicitely that an empty list has an empty items sub-element (section 8.3.1.3), but the XML schema says that the empty items sub-element must be omitted. BLD and FLD may have the same pb (I am not comfortable enough with the notation in the XML mapping to be sure :-).

Note that although Base, Prefix, and Import all use symbols of the form <iri> to indicate the connection of these symbols to IRIs, these symbols are not rif:iri constants, as semantically they are interpreted in a way that is quite different from constants.

So, it would be a clarification rather than an erratum properly said.

Proposed Erratum 6

PRD and BLD disagree on use of xml:base (see also the last item in this comment)

Relative IRIs are allowed in RIF-PRD XML syntax, anywhere IRIs are allowed, including constant types, symbol spaces, location, and profile. The attribute xml:base [XML-Base] is used to make them absolute.

Like the Base directive, the Prefix directives define shorthands to allow more concise representation of constants that come from the symbol space rif:iri (we will call such constants rif:iri constants).

A Base directive in the presentation syntax becomes an xml:base attribute [XML-Base] in the XML Document tag. The base IRI specified as the value of that attribute applies to content of the RIF/XML element that deals with rif:iri constants, namely to relative-IRI content of the <Const type="&rif;iri"> element.

Relative IRIs in RIF documents are resolved with respect to the base IRI.

Based on the discussion and resolution taken during the 2 Feb 2010 telecon, the intent seemed to be as specified in PRD:

RESOLVED: We clarify that relative IRIs are allowed in RIF syntaxes (anywhere IRIs are allowed, including Const rif:iri, symbol spaces, location, and profile), and that xml:base is used in making them absolute; the absolute form is seen and used internally, so that's the lexical space.

Proposed Errata for RIF-PRD

Proposed Erratum 8

According to Definition of Matching Substitution (sect. 2.2.1) the empty substitution does not match the ground formula s[p1->v1] to { s[p1->v1 p2->v2] } since s[p1->v1] does not belong to { s[p1->v1 p2->v2] }.
Is this the intended behaviour?
A related problem is when the action is retract( s[p1->v1] ) applied to state { s[p1->v1 p2->v2] }.
The result according to the specification is apparently { s[p1->v1 p2->v2] }.
Is this the intended behaviour?
In summary, is { s[p1->v1 ... pn -> vn] } equivalent to { s[p1->v1], ..., s[pn->vn]} or not?

Definition (Compound action). A compound action is a construct that can be replaced equivalently by a pre-defined, and fixed, sequence of atomic actions. In RIF-PRD, a compound action can have three different forms, defined as follows:

Assert compound fact: If φ is a frame with multiple slots: φ = o[s1->v1...sn->vn], n > 1; then Assert(φ) is a compound action, defined by the sequence Assert(o[s1->v1]) ... Assert(o[sn->vn]). φ is called the target of the action.

Retract compound fact: If φ is a frame with multiple slots: φ = o[s1->v1...sn->vn], n > 1; then Retract(φ) is a compound action, defined by the sequence Retract(o[s1->v1]) ... Retract(o[sn->vn]). φ is called the target of the action.

Modify fact: if φ is a frame in the RIF-PRD condition language: φ = o[s1->v1...sn->vn], n > 0; then Modify(φ) is a compound action, defined by the sequence: Retract(o s1) ... Retract(o sn), followed by Assert(φ). φ is called the target of the action. ☐

to modify the definition of state of the fact base, section 2.2.2, to restrict Φ to contain only single-slot frames

and to add a note in the definition of frame, section 2.1.2, to say that frames with multiple slots are a shortcut for, and semantically equivalent to conjunctions of single slot frames with the same object.

Proposed Erratum 9

The concept of rule variable is never formally defined (the notion of
rule variable appears afterwards in Section 7.3 and 8.5.1.3 Forall).
My interpretation is the following:
for unconditional action blocks, rule variables are empty (i.e. free
variables).
- for conditional action blocks, rule variables are the free variables.
- for rules with variable declarations, the rule variables are the
universally quantified variables.

Is this correct? Wouldn't it make more sense to equate rule variables
to free variables in all cases?
In this way, universally quantified variables would be ignored for
comparing instances of two rules, while free variables
would be used for that purpose in all cases. This behaviour is
probably more coherent and easier to explain to users.

The term "rule variables" is used to denote the variables that are universally quantified in a rule, to differentiate them from the variables that are existentially quantified in rule conditions, and from the action variables.

Equivalently, the rule variables are the free variables in the conditional action block in a rule after steps 2 and 3 of Core-ification.

Proposed modification (corrected see here): Add the following sentence, after the definition of well-formed group, in section 4.1.4:

"The variables that are universally quantified in a rule are sometimes called rule variables in the remainder of this document, to distinguish them from the action variables and from the existentially quantified variables. The function CVar, that maps a rule to the set of its rule variables is defined as follows:

"If the rule inside a rule with variable delcaration, r1, is also a rule with variable declaration, r2, all the rule variable delarations and all the patterns that occur in r1 (and not in r2) should be added to the rule variable declarations and the patterns that occur in r2, and, after the transform, r1 should be replaced by r2, in the rule set"

for (taking the opportunity to correct the typos as well)

"If the rule inside a rule with variable declaration, r1, is also a rule with variable declaration, r2, all the rule variable declarations and all the patterns that occur in r1 should be added to the rule variable declarations and the patterns that occur in r2, and, after the transform, r1 should be replaced by r2, in the rule set. If the names of some variables declared in r1 are the same as the names of some variables declared in r2, the former names must be changed prior to the transform."

Proposed Erratum 13

The RIF-PRD spec does not say what happens with a rule instance where the rule contains an action variable binding (?v ?o[?p->?v]) and there is no substitution for ?v that matches ?o[?p->?v] to the state of facts for the rule instance substitution of ?o and ?p.

PROPOSED (see also discussion here):
Add a clarification, after the definition of action instance, in section 4.2.3, to the effect that RIF-PRD does not specify a semantics for that case, because the specification of the context where an otherwise valid RIF-PRD rule is validly applicable is out os the scope of RIF-PRD.

Corrected (see here): Added the following paragraph after the definiiton of action instance in section 4.2.3:

Notice that RIF-PRD does not specify semantics for the case where there is no matching substitution for the binding frame formula o[s->vi] in an action variable declaration (vi o[s->vi]). Indeed, although the rule might be valid from an interchange viewpoint, applying it in a context where object o has no value for attribute s is applying it outside the domain where it is meaningful, and the specification of the context where an otherwise valid RIF-PRD rule is validly applicable is out of the scope of RIF-PRD.

Proposed Erratum 14

Erratum 14.1

The semantics of the Assert atomic action is described as follows at:
Rule 1 says that *all the condition formulas that were satisfied before an
assertion will be satisfied after*, and that, in addition, the condition
formulas that are satisfied by the asserted ground formula will be satisfied
after the assertion. No other condition formula will be satisfied after the
execution of the action.
where, Rule 1 is formally defined as:
α is Assert(φ), where φ is a ground atomic formula, and *w' = w ∪ {φ}*;
But an assertion could change the satisfaction of negation formula,
right? ie. a negation formula may be satisfied in w but not in w'.
(A similar argument follows for Rule 2)

PROPOSED (see also reply here): Modify the text explaining the effect of rule 1 and rule 2 to read:

Rule 1 says that all the atomic condition formulas that were satisfied ..., and that, in addition the atomic condition formula that are satisfied ... No other atomic condition formula will be satisfied after the execution of the action.

Rule 2 says that all the atomic condition formulas that were satisfied ... No other atomic condition formula will be satisfied after the execution of the action.

Definition (RIF-PRD transition relation). The semantics of RIF-PRD atomic actions is specified by the transition relation →RIF-PRD ⊆ W × L × W. (w, α, w') ∈ →RIF-PRD if and only if w ∈ W, w' ∈ W, α is a ground atomic action, and one of the following is true, where Φ is a set of ground atomic formulas that represents w and Φ' is a set of ground atomic formulas that represent w' :

α is Assert(φ), where φ is a ground atomic formula, and Φ' = Φ ∪ {φ};

α is Retract(φ), where φ is a ground atomic formula, and Φ' = Φ \ {φ};

α is Retract(o s), where o and s are constants, and Φ' = (Φ \ {o[s->v] | for all the values of v});

α is Retract(o), where o is a constant, and Φ' = Φ \ {o[s->v] | for all the values of terms s and v} - {o#c | for all the values of term c};

α is Execute(φ), where φ is a ground atomic builtin action, and Φ' = Φ. ☐

Proposed Erratum 15

In PRD, a matching substitution for an equality formula is defined wrt the value of ground terms (section 2.2.1). But the value of ground terms is not defined precisely, except for constants in a data types (reported here).

Corrected: see Erratum 16.2, infra.

Proposed Erratum 16

Possibly inconsistent matching substitutions for equality formulas due to incomplete definition in PRD (reported by Jesse Weaver in a private email).

Erratum 16.1

Because RIF-PRD covers only externally defined interpreted functions, a ground functional term can always be replaced by its value. As a consequence, a ground substitution can always be restricted, without loss of generality, to assign only constants to the variable in its domain. In the remainder of this document, it will always be assumed that a ground substitution assigns only constants to the variables in its domain.

But a ground list can be assigned to a variable as well! The purpose of the above sentence is, really, to say that ground external terms can always be replaced by the (non-external) ground term to which they evaluate, and that it will be assumed in the remainder of the document that ground formulas never contain external ground terms (that is, that external ground terms are always replaced by their evaluation in ground formulas). As a consequence, a variable is never assigned an external ground term.

Because RIF-PRD covers only externally defined interpreted functions, a ground positional term can always be replaced by the (non-positional) ground term to which it evaluates. As a consequence, a ground RIF-PRD formula can always be restricted, without loss of generality, to contain no positional term; that is, to be such that any ground positional terms have been replaced with the non-positional ground terms to which they evaluate. In the remainder of this document, it will always be assumed that a ground condition formula never contains any positional term. As a consequence, a ground substitution never assigns a ground positional term to the variables in its domain.

Erratum 16.2

a set of facts \Phi representing a state of the fact base may include
ground, equality, atomic formulas. In that case, the definition of
matching substitution implies: \sigma matches t1=t2 to \Phi iff \sigma(t1)
and \sigma(t2) "have the same value" ***OR*** \sigma(t1=t2) \in \Phi.
So as things are currently defined, it seems there are two ways to match
t1=t2 to \Phi. One is for the two sides to be mapped to the same value,
and the other is to match a fact.

Correct. The problem is that the current definition of a state of the fact base (section 2.2.2) allows the two ways to match an equality to disagree (e.g. if the state of the fact base contains the atomic equality "1^^xs:integer=2^^xs:integer").

PROPOSED: change the definition of state of the fact base, section 2.2.2, to read:

Definition (State of the fact base). A state of the fact base, wΦ, is associated to every set of ground atomic formulas, Φ, that contains no frame with multiple slots and that satisfies all the following conditions:

for every equality formula t1=t2 in Φ, if t1 and t2 are, both, constants in symbol spaces that are data types, then they have the same value;

for all triple of constants c1, c2, c3...

And clarify the definition of matching substitution in section 2.2.1 to read:

the ground terms σ(t1) and σ(t2) are list terms with the same length n≥0 and, for all i, 0≤i≤n-1, such that l1i and l2i are the ground terms of rank i in σ(t1) and σ(t2), respectively, either l1i and l2i are both constants in symbol spaces that are data types and they have the same value, or l1i = l2i ∈ Φ,

or the ground terms σ(t1) and σ(t2) are constants in symbol spaces that are data types and they have the same value;

...

Erratum 16.5

Jesse Weaver noticed that erratum 16.4 introduced the counter-intuitive possibility to equate a constant in a data type and a list, e.g. to a fact base may validly contain fact "3=List()" (see here)

PROPOSED: add the following constraint in the definition of state of the fact base, section 2.2.2:

for every equality formula c1 = c2 ∈ Φ, either c1 is not a constant in a symbol space that is a data type, of c2 is not a list term;.

Proposed Erratum 17

Consider a set of facts \Phi = {c_2##c_1} which represents a state of a fact base.
Consider the following rule:
Do( (?y New()]) Assert(?y#c_2) ) )
By definition of RIF-PRD transition relation (section 3.2), assuming
that the new frame object is identified as _new, the next
state of the fact base is represented by \Phi* = \Phi \cup {_new#c_2},
which is \Phi* = { _new#c_2, c_2##c_1 } .
However,
since _new#c_2 \in \Phi and c_2##c_1 \in \Phi and _new#c_1 \notin \Phi,
then by definition of state of the fact base (section 2.2.2), \Phi*
cannot represent a state of the fact base.

PROPOSED: move the constraint that all members of a subclass must also be members of all the super classes from the definition of a state of the fact base to the definition of a matching substitution, that is

ψ is a membership formula o # c, and there is a ground term c' such that σ matches the conjunction And(o#c' c'##c) to Φ, or

...

Proposed Erratum 18

Action variable binding to a (ground) list (report by Jesse Weaver, see here, last comment).

the definition of action instance requires that d
be a constant, which seems overly restrictive. What if a[p->List()]
\in \Phi, which is allowed by definition of frame atomic formula
(section 2.1.2) and definition of term (section 2.1.1).)

PROPOSED: change the second bullet in the definition of action instance (section 4.2.3) to read:

The Import directive is used to serialize the reference to an RDF graph, an OWL ontology or another RIF document to be combined with a RIF document. The Import directive is inherited from [RIF-Core]. The abstract syntax and semantics of RDF graph and OWL ontology imports are specified in [RIF-RDF-OWL].

Typos, simplifications, clarifications

Remove the confusing and unnecessary condition that "there is at least one term, v, such that o[s->v] is a well-formed frame atomic formula", in the definition of a well-formed Retract with two arguments (see correction here)

Simple, RDF, and RDFS entailment for RIF-RDF combinations are embedded
in RIF Core. RIF-OWL 2 RL combinations require reasoning with equality,
and thus could not be embedded in RIF Core; they are embedded in RIF BLD.

to

Simple, RDF, RDFS and OWL 2 RL entailment for RIF-RDF combinations are
embedded in RIF BLD.
Note that Simple, RDF and RDFS entailments are superficially embeddable
within RIF Core. However, condition 7 of the semantics of RIF-RDF
combinations cannot be axiomatized in RIF Core due to restrictions on
the use isa (#) in rule heads. OWL 2 RL is not embeddable in RIF Core
due the the need for equality reasoning.

Proposed Errata in DTB

(Proposed by Axel, who commented:
"Summarizing, I do understand that only 1)+5) are mandatory changes,
whereas the changes 2)- 4) are not necessarily mandatory, but would
make the RIF-DTB spec cleaner.")

Any remaining issues would in my opinion depend on whether the Xpath working group sees any effects on [XPath-Functions], since we don't have any other direct dependencies on [XML Schema Datatypes], but only indirectly by reuse of definitions from [XPath-Functions].

all point to the first edition recs and should probably be updated to the Dec 2010 Second Edition versions.

2)

In fact, it seems that the reference to [XDM] could be removed, since we only needed it because the two subtypes of duration we are referring to didn't appear in the earlier version of [XML Schema Datatypes].

4) Section 2.3

Similarly, the following could be changed/simplified, if we refer to the leatest [XML Schema Datatypes] version:

Their value spaces and the lexical-to-value-space mappings are defined as follows:

.For the XML Schema datatypes of RIF, namely all RIF datatypes within the xs: namespace, except xs:dayTimeDuration and xs:yearMonthDuration, the value spaces and the lexical-to-value-space mappings are defined in the XML Schema specification [XML Schema Datatypes].
.The value spaces and the lexical-to-value-space mappings for the datatypes xs:dayTimeDuration and xs:yearMonthDuration are defined in the XQuery 1.0 and XPath 2.0 Data Model [XDM].

to

Their value spaces and the lexical-to-value-space mappings are defined as follows:

.For the XML Schema datatypes of RIF, namely all RIF datatypes within the xs: namespace, the value spaces and the lexical-to-value-space mappings are defined in the XML Schema specification [XML Schema Datatypes].