W3C home > Mailing lists > Public > public-rif-comments@w3.org > October 2008

Re: Fwd: comments on the BLD proposal

From: Chris Welty <cawelty@gmail.com>
Date: Sat, 18 Oct 2008 20:17:21 -0400
Message-ID: <48FA7C91.8070108@gmail.com>
To: Alexandre Riazanov <alexandre.riazanov@gmail.com>
CC: public-rif-comments@w3.org

Alexandre Riazanov wrote:
 >>> (3) Use case 4.2 in http://www.w3.org/TR/2008/WD-rif-ucr-20080730/ uses
 >>> frames as (individual-valued) base terms.
 >>> The BLD spec does not seem to provide either syntax or semantics for such
 >>> use. Does it mean that such use was
 >>> considered initially but didn't make it to the spec?
 >> The syntax and semantics do specify individual-valued frames, one of their
 >> most obvious uses on the semantic web is for RDF triples. What leads you to
 >> believe that the syntax or semantics are not provided? Or perhaps you mean
 >> something different by "(individual-valued) base terms".
 >> e.g. the RDF triple
 >> <http://ex.com/john> <http://ex.com/uncleOf> <http://ex.com/mary>.
 >> can be written in the frame syntax as
 >> <http://ex.com/john>[<http://ex.com/uncleOf> -> <http://ex.com/mary>]
 >> where <xxx> is a shortcut for xxx^^rif:iri.
 > The triple above is obviously a statement which can
 > only have a boolean value. The frame can also be interpreted
 > as a statement (equivalent to the triple), but it can
 > also be used in a place where a resource-valued term is
 > expected, e.g. it can be the filler in a property:
 > <http://ex.com/paul>
 >    [
 >       <http://ex.com/father> ->
 >            <http://ex.com/john>
 >                [<http://ex.com/uncleOf> -> <http://ex.com/mary>]
 >    ]
 > In this case, the value computed by the frame is just <http://ex.com/john>,
 > which is not boolean.  The slots can be considered as qualifiers
 > of <http://ex.com/john> and have to be treated semantically as,
 > for example, additional constraints on <http://ex.com/john>.
 > This is, of course, syntactic sugar.

OK - frames don't "compute values". Your example is supported, and would be 
syntactic sugar for

  <http://ex.com/paul> [<http://ex.com/father> -> <http://ex.com/john> ]
  <http://ex.com/john> [<http://ex.com/uncleOf> -> <http://ex.com/mary> ]

Both of these frame terms are truth-valued, that is, both of them are either 
true or false. Being able to nest them, as you wrote, is simply a slight shorter 
way of writing the conjunction, but it is important to realize that it is a 
shortcut to a conjunction, not "individual valued frames".

 > Nether syntax, nor semantics of BLD covers such use, and I am actually
 > fine with this in principle. The only problem is that the use case 4.2
 > has "?buyer[card -> ?creditCard deliveryAddr -> ?address]" as the second
 > argument of the (positional) predicate "provide", and also
 > "?date[month -> ?month year -> ?year]" as a filler for "expiry",
 > and several other examples like this.

Hopefully it is clear that this is supported, and again is simply a shortcut to 
writing a conjunction of frame terms.

 >>> (4) In general, it would be extremely helpful (to me as an implementer) to
 >>> see a reference translation to FOL.
 >>> IMHO, the standard would be the right place for it.
 >> By "reference translation to FOL" do you mean to take a set of BLD Formulae
 >> and translate them to FOL sentences? Or a logical embedding of the semantics
 >> of BLD in FOL?
 > The latter. As an implementor, I would prefer the semantics
 > written as a translation to FOL to the model-theoretic semantics (this one
 > is good too, but for other purposes).

I think I know what you mean, but I don't think you said it. FOL semantics is 
normally expressed as a model theory, and a fully first-order model theory is 
how the semantics of BLD were specified. But I believe you would like to see the 
entailment rules of BLD expressed as FOL axioms.

Assuming that is what you mean, then we don't have the resources to provide such 
a translation within the working group. Hopefully someone outside the group will 
take the time to do it. I agree it would be useful. One thing you may find 
useful are the test cases. See 
http://www.w3.org/2005/rules/wiki/Category:Test_Case for an evolving list.

 >>> (5) Minor thing: isn't External(c) a well-formed (base) term when c is a
 >>> constant?
 >> No, See Section 2.2, Item 8. External is meant to be an anchor for an
 >> external function call, so External(c) is not a term, but External(c()) is.
 > Then it overrides clause 7 in 2.4 in the FLD spec, that
 > says "If t is a constant, .. then External(t) is an *externally defined term
 > *."

This can be a bit confusing. FLD provides a *framework* that allows a RIF 
dialect to make External(t) valid. So you can imagine a dialect where a frame 
identifier could be used in an external, indicating e.g. some kind of query to 
an external source for an object. In BLD, however, there is a syntactic 
restriction against this. You'll note, in fact, throughout FLD are elements that 
are not supported in BLD.

Thanks again for your comments.


Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
Received on Sunday, 19 October 2008 00:18:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:49:19 UTC