Re: my personal reply to (Re: comments on RIF BLD from OWL WG)

Peter,

Apologies for the long delay, this message from Jan. 29 slipped through
one of the larger cracks in my less-than-adequate administrative skills.
Jos and I went over your comments and responded below. The only one we're
not sure if we've tied up is the first one.

-Chris

 > From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
 > Date: Tue, 29 Jan 2008 12:54:00 -0500 (EST)
 > Message-Id: <20080129.125400.114044706.pfps@research.bell-labs.com>
 > To: cawelty@gmail.com
 > Cc: public-rif-comments@w3.org, public-rif-wg@w3.org, public-owl-wg@w3.org
 >
 >
 > From: Chris Welty <cawelty@gmail.com>
 > Subject: Re: comments on RIF BLD from OWL WG
 > Date: Tue, 29 Jan 2008 10:28:44 -0500
 >
 >> Peter,
 >>
 >> Here are responses to your message "from the OWL WG" to RIF public
 >> comments on  Nov. 2.  Feel free to forward to the owl-wg, I cannot
 >> post to it.
 >
 > I did so.  Here is my personal reply to the responses.  I have taken the
 > liberty of reformatting the dialog as it had some long lines.
 >
 > peter
 >
 >> > ** Comments on the Syntax
 >>
 >> > Why is the complex signature mechanism in this document, as the only
 >> > used language doesn't really need it?
 >>
 >> Signatures are part of the general framework of RIF from which other
 >> dialects are to be derived. This general framework has meanwhile been
 >> split off of the dialect specification, resulting in the FLD [BLD?]
 >> document.
 >>
 >> > Further, the signature mechanism
 >> > cannot capture the syntax of the BLD condition sublanguage, so it is
 >> > not even adequate for distinguishing between dialects.
 >
 >> This question is quite unclear.  The signature mechanism is intended
 >> to be used for defining and extending RIF dialect semantics.  Can you
 >> be more specific?  What do you mean by the inability to "capture" the
 >> syntax and why it is relevant?
 >
 >>From the document section
 > http://www.w3.org/TR/rif-bld/#Slotted_Conditions
 >
 > | Slotted signatures for RIF-BLD:
 > | [...]
 > | In addition, RIF-BLD imposes the following restrictions:
 > | * The terms that are allowed as slot names in slotted terms
 > |   o must have the signature term{ }; and
 > |   o they must be constant symbols.
 > | This means that RIF-BLD does not allow variables or complex terms
 > | (like f(), f(a,b)) as slot names in slotted uniterms (but there are no
 > | such restrictions on slots in frames).
 >
 > This last is the case even if f() has the correct type.  Therefore the
 > signatures are not adequate for defining RIF-BLD syntax.

The signature mechanism for defining BLD has been revamped.
Either the problem you are referring to was fixed, the context
of your message has been lost by the change, or we don't
understand what your point is.  If there is a specific problem
with the signatures definition for BLD, please point it out.

Note that "slotted terms" are now called "named arguments" to
avoid confusion with slots in frames.  This may have been the source
of your comment, not sure.

 >> > Why are there are three different kinds of atomic formulae (regular,
 >> > slotted, and frame)?  This could cause problems with OWL
 >> > integration, as
 >> > it is not obvious which kind of formulae should be used for
 >> > integration
 >> > with OWL.  In particular, frame formulae might be the target for OWL
 >> > Full and regular formulae the target for OWL DL.
 >
 >> The three kinds of formulae are related formally and, in fact, we
 >> expect frames to provide a natural way to anchor the OWL integration
 >> work.  The others are present because the RIF framework is intended to
 >> capture all the major types of atomic formulas used in rule languages.
 >
 > Frame formulae do not match up with OWL DL very well, as components of
 > frame formulae are terms.  OWL DL is a standard first-order logic,
 > where predicates are not terms.  Therefore OWL DL matches up much
 > more closely to regular formulae than to frame formulae.

The RDF and OWL compatibility document specifies that frame formulae should
be interpreted differently when considering OWL DL compatibility, to match
up with the OWL DL semantics.

See:
http://www.w3.org/2005/rules/wg/draft/rif-rdf-owl/#OWL_Compatibility

 >
 >> > * Semantics of the RIF BLD Condition Sublanguage
 >> >
 >> > The semantics is only for the RIF BLD Condition Sublanguage, not the
 >> > full RIF Condition Sublanguage.
 >
 >> At present we are specifying RIF-BLD.  Other dialects will be
 >> specified separately and in due time.  The "Condition Language"
 >> distinction will be removed in future drafts and the syntax &
 >> semantics merged into the apprpriate BLD sections.
 >
 > OK.
 >
 >> > * Comments on the Semantics
 >> >
 >
 >> > The mappings for predicates are partial.  It seems that this means
 >> > that the truth value of some formulae are thus undefined, but no
 >> > account is taken of this in the later development of the semantics.
 >
 >> This has been fixed.
 >
 > A pointer to the changes would be appreciated.

As you can see in the section defining semantic structures, the interpretation
functions and truth value mappings are now total:

http://www.w3.org/TR/rif-bld/#Semantic_Structures

 >> > Why is a new treatment of data values needed?
 >
 >> The treatment is not new -- it is equivalent, but more uniform. It was
 >> chosen for its uniformity, since the same mechanism can be used other
 >> RIF needs: data types and other kinds of symbols (IRIs and local).
 >
 > Well, the new treatment is similar, but somehow less general.  In
 > particular it does not handle ill-formed literals like "a"^^xsd:decimal
 > in the same way that RDF does.  There may be reasons for this
 > difference, but the difference should be defended.

Ill-formed literals are syntax errors and are treated as such in RIF.
That is, ill-formed literals are not legal symbols, and any ruleset
containing ill-formed literals is not well-formed RIF.

 >
 >> > Why does the set of known
 >> > data types not include XSD data types like xsd:short?
 >
 >> It was decided to start with a subset of the data types.  There is no
 >> technical reason to exclude xsd:short and others. They might be
 >> included in the future.  It is also not clear why an exchange language
 >> needs to support all the XML data types.
 >
 > I would have expected that RIF would support the datatypes supported by
 > RDF XSD datatypes at http://www.w3.org/TR/rdf-mt/#dtype_interp

We discussed your comment and decided to make BLD more flexible.

The definition of BLD now allows for implementations to support datatypes
outside the required set as long as there is some user control over strictness.
This is a compromise, but many WG members felt that too long a list of
datatypes (like those you referenced) would increase the burden on
implementors and raise the barrier to entry. (See the new conformance
section 5, which defines conformance wrt the supported datatypes).

 >> > Why does there need to be a symbol space for IRI identifiers?  This
 >> > may cause problems with OWL integration.
 >
 >> This symbol space corresponds to RDF's resources. Which problem can it
 >> cause for OWL?
 >
 > How is one to determine whether to use a symbol space constant
 > "http://ex.com/john"^^rdf:iri or a regular constant http://ex.com/john
 > for an OWL URI?

In RIF, one can only use symbol space constants, so the user has no choice.

 >> > The treatment of slotted formulae is unusual in that the predicates
 >> > have a direct map to their extension but the slot names are first
 >> > mapped into the domain.  This means that a=b implies that f[a->3] is
 >> > equivalent to f[b->3].
 >
 >> In what sense is it "unusual"? It is usual in F-logic, but can be
 >> prevented by signatures (in dialects).  To be elaborated upon in the
 >> followup draft.
 >
 > Does F-logic even have slotted formulae?  I guess by "unusual" I was
 > saying that the treatment of slot names as denoting values or elements
 > of the domain is not what I think of when one I see slotted notation in
 > either programming languages or logic.  Instead I think of the slot
 > names as (only) names.
 >
 > I wonder how "a=b implies that f[a->3] is equivalent to f[b->3]" can be
 > prevented in RIF dialects.

This cannot be prevented in general in RIF. Specifically, in BLD one can
write this.

 >> > * General Comments on the Condition Language
 >> >
 >> > The language is very complex.  It appears to have been designed to
 >> > mirror several other languages.  In particular, the frame formulae
 >> > appear to have been designed to mirror F-logic.
 >
 >> > The logic is not like RDF, as it is monomorphic and predicates are
 >> > not first mapped into domain elements.
 >
 >> This is intended to be changed in the next draft.
 >
 > It is?  Does this mean that regular formalae are going to be treated
 > as in RDF?

No.  Frame formulas are treated as in RDF.  Predicate formulas are treated
as in standard FOL.  Note that RDF properties are not predicates but slot
names in the RDF compatibility section.

 >> >  The frame part of the logic is not
 >> > like regular frames, as the slot names are first mapped into domain
 >> > elements.
 >>
 >> What is a "regular" frame?
 >
 > I was thinking of the various frame languages from the past (such as
 > FRL and KRL) in which one does not think of the slot names in frames as
 > denoting values, but instead thinks of them as names.  Of course,
 > F-logic has a different view of frames.

Yes, RIF frames are not like this, they are much simpler.  As you point out,
slot names are just domain elements and really just syntactic sugar.

 >> > * Notes on RIF-RDF compatability
 >> >
 >> > Why worry about interpretations where IP is not a subset of IR?
 >> > This only happens in simple entailment.  As there are already
 >> > datatypes in RIF why not just go to datatype-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].
 >
 > OK.

In the meantime we have decided to keep all entailment regimes in there.
IP is not defined as a subset of IR because it is not a subset in simple
entailment.  In the other entailment regimes it is.

Note that datatype entailment in RDF is significantly harder than the
treatment of datatypes in RIF because of the equality of value spaces
and class extensions of datatypes in D-entailment. RIF features unary
predicates that are interpreted as the value spaces of datatypes, but
these may only be used in rule bodies.

 >> > The treatment of ill-typed literals appears to allow accidental
 >> > capture
 >> > if the replacement IRI also occurs in the RDF graph.  For example,
 >> >    "abc"^^xsd:decimal ex:a ex:b .
 >> > RIF-RDF entails
 >> > 
http://www.w3.org/2005/rif/rdf-ill-typed-literal/uri-encode("abc"^^xsd:decimal)
 >> >    ex:a ex:b .
 >
 >> 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].
 >
 > Hmm.  Wouldn't it be better to eliminate these sort of artifacts?

The elaborate description of the treatment of the ill-typed literals has
been removed from the RDF and OWL compatibility document, so the reader
is not really need to be bothered with them.

We cannot eliminate these artifacts. It is not up to us to disallow the
use of ill-typed literals in RDF.  They are there.

 >> 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].
 >
 > Hmm.  This doesn't seem like a good idea.

We agree that the situation is not ideal, but it is an artifact of the
way symbols are defined in RIF.

 >
 >> > Note that rdf:type is not related to membership formulae (i#c) and
 >> > rdfs:subClassOf is not related to subclass formulae (c1##c2).  This
 >> > does
 >> > not seem to be reasonable.
 >>
 >> 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].
 >
 > OK.  This may be a change from the version I reviewed.

Yes, this was a change.

 >
 >> > * RIF-OWL Compatability
 >
 >> > There was a section on RIF-OWL compatability in an earlier draft of
 >> > the document but it has been removed.
 >
 >> > * Notes on RIF-OWL Compatability.
 >
 >> > There is a question as to which part of the syntax OWL should map
 >> > to.  There is also a question as to whether OWL syntax should map to
 >> > RIF facts.
 >
 >> The questions will be addressed by the recently established OWL-RIF
 >> taskforce.
 >
 > Nice pass.  :-)
 >
 > peter


-- 
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, 17 June 2008 14:33:27 UTC