Warning:
This wiki has been archived and is now read-only.

Response to AR2

From RIF
Jump to: navigation, search
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