Response to AR2

Alexandre Riazanov wrote:
>>> (3) Use case 4.2 in 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
>> <> <> <>.
>> can be written in the frame syntax as
>> <>[<> -> <>]
>> 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:
> <>
>    [
>       <> ->
>            <>
>                [<> -> <>]
>    ]
> In this case, the value computed by the frame is just <>,
> which is not boolean.  The slots can be considered as qualifiers
> of <> and have to be treated semantically as,
> for example, additional constraints on <>.
> This is, of course, syntactic sugar.

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

 <> [<> -> <> ]
 <> [<> -> <> ]

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


Last modified on 15 October 2008, at 00:59