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

-------- Original Message --------
Subject: my personal reply to (Re: comments on RIF BLD from OWL WG)
Date: Tue, 29 Jan 2008 12:54:00 -0500 (EST)
From: Peter F. Patel-Schneider <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
References: <20071102.055600.96493878.pfps@research.bell-labs.com> 
<479F462C.6050903@gmail.com>

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.

> > 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.

> > * 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.

> > 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.

> > 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

> > 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?

> > 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.

> > * 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?

> >  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.

> > * 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.

> > 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?

> 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.

> > 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.

> > * 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, 5 February 2008 16:13:15 UTC