Re: Fwd: comments on the BLD proposal

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

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

-The RIF WG

-- 
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 Sunday, 19 October 2008 00:18:06 UTC