Re: Questions and Comments on RIF Basic Logic Dialect document

Peter,

Here is a response to your public-comments message of Oct. 19th.  Apologies for 
the delay, it was a long message.  Thanks for the feedback, many of your 
suggestions were incorporated into BLD:


 >       Questions and Comments on RIF Basic Logic Dialect
 >       (undated version, downloaded 15 October 2007)
 >       Peter F. Patel-Schneider
 >
 > I have a number of questions and comments (mostly questions) on the RIF
 > Basic Logic Dialect document.  Answers to the questions may result in
 > further comments.
 >
 > I downloaded the document on 15 October 2007, which should have gotten
 > me the frozen version.
 >
 > 1/ The presentation of the RIF Condition Language is made unnecessarily
 >    complex by its division into two parts.  I suggest presenting the
 >    language all at once.

The reason was that while "2.1 Positive Conditions" presents a language closer 
to Pure Prolog,
"2.2 Slotted Conditions" presents a language closer to Pure Production Systems.
These parts thus reflect two major communities addressed by RIF, lowering
their barriers to entry.

The next version will have these parts merged however.

 > 2/ The RIF Condition Language has a very complex syntax.  However, the
 >    condition sublanguage of the RIF BLD does not use this complexity.
 >    I suggest removing the development of the RIF Condition Language and
 >    instead just presenting the condition sublanguage of the RIF BLD.
 >    Alternatively, but less desirable in my mind, would be to present the
 >    RIF Condition Language in an appendix.
 >

This has been taken care of in the current draft by splitting off the
"Framework for Logic Dialects" (http://www.w3.org/2005/rules/wg/wiki/FLD/).

 > 3/ Why is it obvious that different symbol spaces cannot share an
 >    identifier?

By definition.

 > 4/ Why are built-in derived XSD datatypes like xsd:int not required RIF
 >    symbol spaces?  Why is xsd:integer the only derived datatype in
 >    required RIF symbol spaces?  Why are xsd:date, xsd:boolean,
 >    xsd:float, and several other built-in primitive XSD types not in the
 >    required RIF symbol spaces?  I suggest expanding the required RIF
 >    symbol spaces to cover all the useful built-in XSD datatypes.

There is no strong technical argument for the restricted set, other than WG 
agreement to start small in this WD and expand as needed.  Clearly the set of 
"all useful XS Datatypes" varies depending on who you ask.

 > 5/ How do the intended meanings for rif:iri and rif:local affect the
 >    semantics of the condition sublanguage of the RIF-BLD?

They are part of the semantics of BLD and are intended for different purposes.


 >
 > 6/ Following the pointer to the list of builtin predicates in the
 >    W3C-style version of the document results in a 404 error.

Fixed.

 > 7/ What is the arity of the builtin symbol
 >    http://www.w3.org/2005/xpath-functions#Imadethisup ?

Since this isn't a pre-defined builtin nor valid RIF syntax the arity would be 
determined by the uses of that symbol.

 > 8/ Where are the semantics for the builtin predicates?

They will be given fixed interpretations much like for SWRL builtins.

 > 9/ Since the condition sublanguage for RIF-BLD can distinguish between
 >    individual symbols, predicate symbols of each arity, and function
 >    symbols of each arity by context, why not include this distinction in
 >    the presentation syntax?

Why is it necessary?

 >
 > 10/ Is it true that disjunction can be eliminated in *all* rule
 >     formalisms (including operational ones)?

Disjunction cannot be eliminated in some operational languages - however BLD is 
a basic logic dialect, and this statement should apply to rule languages based 
on BLD or its "core".

 >
 > 11/ Is the restriction in the condition language of the RIF-BLD relating
 >     to the appearance of quantified variables carried over into the RIF
 >     condition language?

There is only one condition language for BLD, which the text occasionally refers 
to as the RIF condition language.

 >
 > 12/ Why do constant symbols used (only) as predicate and function
 > symbols
 >     have to have a denotation in the model theory for the condition
 >     language of RIF-BLD?

Symbols used as individuals also must have denotations.

 >
 > 13/ Why are mappings for predicate symbols (IR) partial?  What happens
 >     in the semantics for predicate applications that are not in the
 >     domain of the predicate?

Do you mean why are the mappings in IR not total mappings? If they were that 
would address the second part of your question.  Perhaps they should be, 
restricted perhaps by the signature.

 >
 > 14/ Why is the treatment of datatypes different in RIF from their
 >     treatment in RDF?  I suggest using the same treatment.

It has since been decided to semantically homogenize the treatment, with the 
distinction that RIF implementations are required to recognize all datatypes 
used in a rule sets, or reject the rule set.
There is still a distinction in the syntax: RDF has four kinds of constant 
symbols: three kinds of literals and IRIs.  RIF has one kind of constant symbol: 
pairs of strings and symbol space IRIs; different symbol spaces correspond to 
different kinds of constant symbols and different data types.

 >
 > 15/ It is not really the case that slotted terms have "named" arguments,
 >     because the argument "names" are interpreted.  Instead slotted terms
 >     have paired, unordered arguments.  I suggest using some other
 >     wording.

It has since been decided to not interpret the names.

 >
 > 15a/ Is t() a slotted term or a regular term?

It is both positional and slotted.

 > 16/ Why is "assumed" used in the definition of signatures for slotted
 >     terms?  Either the order is immaterial or it is not.

Fixed.

 >
 > 17/ Why are the first part of the arguments to slotted terms not allowed
 >     to be slotted terms?

Actually, even the use of positional terms for slot names was an overkill. The 
next version will simplify
slotted terms even further.

 >
 > 18/ Suppose that name and age are constant symbols with the same
 >     signature, e.g., term{}.  Then either both or neither of
 >     Person(name->"a") and Person(age->"a") are well-formed.  Why cannot
 >     signatures make a distinction between these two terms?  Most
 >     languages that allow named arguments can make these distinctions.


Fixed.


 > 19/ Why are the signatures of the terms used in membership, subclass,
 >     and frame formulae not used to determine the well-formedness of
 >     these formulae?

Fixed.

 >
 > 20/ Why are slotted well-formed terms not allowed in membership,
 >     subclass, or frame formulae?

Slotted terms as class names seem not be needed in RIF 1.0, so we simply use
TERM ' # ' TERM | TERM ' ## ' TERM.

 >
 > 21/ Why are frame formulae that include other frame formulae part of the
 >     basic syntax?  They are stated to be shorthand, but only
 >     half-defined as such.  Why not make them really into shorthands?

Cannot understand the question. What do you mean "half-defined"?


 > 22/ It appears that the signature mechanism cannot capture the syntax of
 >     the condition language of the RIF-BLD.  Is this the case?

Again, the question is quite unclear. Please elaborate what do you mean by the 
inability to "capture" the syntax.


 > 23/ Are the mappings for ISF, etc., total or partial?

Total.

 >
 > 24/ It is not just that slotted function and predicate applications can
 >     have the first element of their pair arguments map into the same
 >     domain element, it is also the case that these first elements can be
 >     repeated verbatim, as in married(spouse->Jack,spouse->Jill) or even
 >     married(spouse->Jack,spouse->Jack).

Yes. It is not clear why this should be precluded.


 > 25/ The use of set notation in the definition of Itruth for slotted
 >     function and predicate applications is unfortunate, as these are
 >     bags, not sets.

Yes, we should make it clearer notationally, or at least textually, that
these are bags or multisets.

 >
 > 26/ V*U and V*PL turn RDF names into constant symbols in symbol spaces.
 >     V*TL is defined as turning RDF names into constant symbols not in a
 >     symbol space, but later constant symbols that look like the result
 >     of V*TL given as if they were in a symbol space.  What is the status
 >     of V*TL?  (I'm assuming that it does map into a symbol space.)

Indeed, typed literals are mapped to symbol spaces. Note, however, that the 
definition of the set V*TL has been removed in the 
[http://www.w3.org/TR/rif-rdf-owl/ current working draft], because its 
definition was redundant.
It can be seen from condition 7 in 
[http://www.w3.org/TR/2007/WD-rif-rdf-owl-20071030/#head-7bc418db41931aa0bec2cdadef81be12759c6807 
section 2.2.1.2] that symbols in symbol spaces are interpreted in the same way 
as typed literals.
The example below the conditions shows one thing which is implied from this 
correspondence and the correspondence between IRIs in RDF and symbols in the 
rif:iri symbol space in RIF: in combinations with RIF: IRIs and corresponding 
literals with the rif:iri data type are interpreted in the same way.

 >
 > 27/ Given that RIF-RDF combinations need datatypes, why not just only
 >     define the combination for D-entailment?

It is at the moment not clear which entailment regime(s) will be useful for RIF. 
  It might be the case that we decide to use only D-entailment.  See also the 
second last paragraph in the 
[http://www.w3.org/TR/2007/WD-rif-rdf-owl-20071030/#Overview introduction].

 >
 > 28/ Point 4 of common interpretations is not very well stated.  What is
 >     the set of datatypes used?  Is it all the datatypes in D?

No, it is the set of all datatypes supported by RIF.  Note that, in case 
D-entailment is used, LV will include all values spaces in D, due to the 
definition of D-interpretations.

 >
 > 29/ RIF-RDF combinations appear to add extra entailments on the RDF
 >     side.  For example
 >        "abc"^^xsd:decimal ex:a ex:b .
 >     appears to RIF-RDF entail
 > 
http://www.w3.org/2005/rif/rdf-ill-typed-literal/uri-encode("abc"^^xsd:decimal)
 >       ex:a ex:b .
 >     I don't think that this is a good idea, and suggest that it should
 >     be the case that RIF-RDF entailment matches RDF D-entailment when
 >     there are no rules.

There was already general skepticism in the working group about using such an 
IRI encoding of ill-typed literals.  It was decided to remove this encoding, so 
that it is no longer possible to directly use ill-typed literals in RIF rules.
See also the example in 
[http://www.w3.org/TR/2007/WD-rif-rdf-owl-20071030/#RDF-Compatibility section 2].

Note that it is, however, not the case that RIF-RDF entailment matches RDF 
D-entailment when the set of rules is empty; see the example at the bottom of 
[http://www.w3.org/TR/2007/WD-rif-rdf-owl-20071030/#head-7bc418db41931aa0bec2cdadef81be12759c6807 
section 2.2.1.2].

 >
 > 30/ Why is rdf:type is not related to membership formulae (i#c) and
 >     rdfs:subClassOf not related to subclass formulae (c1##c2)?  I
 >     suggest that they should be related.

In the [http://www.w3.org/TR/2007/WD-rif-rdf-owl-20071030/ current draft] they 
are related; see 
[http://www.w3.org/TR/2007/WD-rif-rdf-owl-20071030/#head-0d9bc055f4ca271102e7b53420888f3818628265 
section 2.2.1.2.1].



-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Tuesday, 29 January 2008 15:27:20 UTC