Warning:
This wiki has been archived and is now read-only.
Response to AR2
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