Re: AW: Outcomes from 12/19 telecon

Harold,

Rather than commenting on Hassan's proposal to use signatures, (I 
think) you continued to explain your keyword -> positional 
transformation approach and re-presented the problem with "&rest" 
style unification in the positional->keyword transformation.

The problem with the keyword -> positional approach as I saw it was 
that in a keyword syntax a "missing" argument unifies with anything, 
however in your translation a missing argument unifies with nothing, e.g.

(P subject:Chris) should unify with (P subject:Chris object:Darren), 
but you translate (P subject:Chris) into (P _|_ Chris) and (P 
subject:Chris object:Darren) into (P Darren Chris) and the two do not 
unify.

Hassan suggested adding predicate signatures to the positional -> 
slotted approach to address your "&rest" concern, that is the 
suggestion I was looking for you to "weigh in" on.

Thanks,
Chris




Boley, Harold wrote:
> Hi Chris and Hassan,
> 
> In the spirit of regarding slots as (named-argument) syntax (cf. charter)
> and of keeping things simple in Phase 1, I think that slotted arguments
> should for now reflect the ‘closed’ semantics of positional arguments.
> 
> This is further explained below through inlined ‘HB>’ comments.
> 
> Using ‘closed-slot’ semantics, if n is the maximum arity in a positional
> system, we can round-trip
> s(t_1, …, t_i, …, t_n)
> (via the pos2slot shortcut) to
> s{1->t_1, …, i->t_i, …, n->t_n}
> and (via the slot2pos transformation), since 1<…<i<…<n, back to
> s(t_1, …, t_i, …, t_n).
> If n is less than the maximum arity, we end up in a ‘replenished’
> normal form (with ‘_|_’ elements for the missing higher positions),
> s(t_1, …, t_i, …, t_n, _|_, …, _|_).
> 
> Best,
> Harold
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: public-rif-wg-request@w3.org im Auftrag von Hassan Aït-Kaci
> Gesendet: Di 19.12.2006 22:16
> An: Chris Welty
> Cc: Public-Rif-Wg (E-mail)
> Betreff: Re: Outcomes from 12/19 telecon
> 
> 
> Chris Welty wrote:
> 
>  > The telecon discussion went on quite long today and we didn't have time
>  > for everything on the agenda.  I felt like we were near resolution on a
>  > few issues but didn't quite get there, so I'd like to summarize where I
>  > think we are. Overall I'm quite happy to see that we are finally
>  > starting to deal with concrete technical issues.
> 
> Hi Chris,
> 
> I agree and share the feeling. I also agree that reviewing where we now
> stand excatly is in order.
> 
>  > Hassan proposed at the f2f to use constraints as a way to connect a
>  > keyword syntax with a positional syntax, by mapping positional syntax
>  > into keyword syntax.
> 
> HB> In the F2F4 breakout session we considered the positional-to-slotted
> HB> mapping (pos2slot), assuming i<n, from
> HB> s(t_1, …, t_i, …, t_n) to
> HB> s{1->t_1, …, i->t_i, …, n->t_n}.
> HB> Here, the curly braces {…} express both:
> HB> * An unordered collection of the slots i->t_i
> HB> * An application of s to the slots i->t_i
> HB> Each natural-number slot name i stands for rif:i, but can also be
> HB> regarded as rdf:_i, argi, or as a similar positional name.
> 
>  > Harold later found that the specific syntax
> 
> Not "syntax" but "semantics" of \psi-terms (which are equivalent to OSF
> constraints in solved form). The \psi-term syntax is a simple generalization
> of the FOT syntax:
> 
>         Psi ::= X:s(f_1=>Psi_i, ..., f_n=>Psi_n)
> 
> (one may use '=' instead of :, and -> instead of => - matter of taste)
> where X is optional and n can be 0. Like FOT, these constructs can be
> used to model data with all kinds of intended semantics, and well-formedness
> conditions may be added (like fixed/flexible arity, partial/total features,
> etc, ...) in the same way a *schema* or DTD describes well-formed elements.
> Such well-formedness can be enforced using (static or dynamic) constraint
> normalization rules. Hence, a rather expressive family of different 
> semantics
> can thus be ascribed to the above "slotted" syntax depending of the 
> signature
> axioms making up the desired schema. My point thus is that this is a cleaner
> and simpler solution to accommodate various differring behaviors for the
> same syntax. In particular, there is no need for contrived notational tricks
> such as proposed by Harold (some kind of continuation variable notation).
> Notwithstanding whether it is correct and/or would work as he intends, it
> is a hack to accommodate just one specific semantic discrepancy (viz.,
> flexible or open arity vs, fixed arity symbols). What about other possible
> discrepancies? Shall we introduce a hack to accommodate each one that we
> recognize? I don't think so! By contrast, using well-delineated schema
> constraints for enforcing well-formedness and other such integrity
> constraints is both more expressive (simply specify the signature
> constraints for your desired semantics), and simpler. Finally, since
> the above slotted syntax is simple and can be mapped to several differring
> semantics of slotted terms depending on its symbol signature schemata,
> I thought it would be a good candidate for the minimal slotted syntax
> we are after. How this minimal syntax is desugared in the (normative)
> constraint form depends on the semantics enforced by the chosen signature
> schema, and its solving semantics on that of the constraint system it
> desugars into.
> 
> Therefore, Harold mistakenly understood that I was proposing a semantics
> for slotted terms.
> 
>  > proposed by Hassan created a problem with unifying variable arity
>  > predicates, that is that (P x y) would unify with (P x),
> 
> HB> For an ‘open-slot’ (or ‘subsumption’) semantics of slotted forms
> HB> s{1->t_1, …, i->t_i, …, n->t_n} unifies with s{1->t_1, …, i->t_i}.
> HB> Assuming that the above pos2slot mapping is employed to interpret
> HB> positional forms as a shortcut of (position-named) slotted forms,
> HB> s(t_1, …, t_i, …, t_n) would wrongly unify with s(t_1, …, t_i).
> HB> For a ‘closed-slot’ semantics this problem does not arise, since
> HB> the above slotted forms would no longer unify, so their shortcut
> HB> versions wouldn’t either.
> 
>  > and Harold
>  > proposed a solution that maps keyword syntax into positional.  A few of
>  > us were unsure on the telecon today that the proposal as it stood (using
>  > 'bottom' to substitute for missing parameters) would work, as bottom
>  > unifies with nothing, which would create unexpected results compared to
>  > keyword systems.
> 
> HB> This slotted-to-positional mapping (slot2pos) can be employed, for
> HB> a ‘closed-slot’ semantics of slotted forms, to avoid that slots need
> HB> to be dealt with in the model theory.
> HB> Currently, ‘_|_’ or owl:NOTHING is used as a distinguished element
> HB> for slots missing in (positionalized) forms to express their ‘N/A’-like
> HB> NULL-value interpretation: ‘_|_’ is equal to itself, and unequal to any
> HB> ordinary (non-‘_|_’) term.
> 
>  > Hassan suggested that keeping the mapping of positional
>  > onto keyword would work if we also introduced function signatures, which
>  > could prevent unifying a binary predicate with a unary one when it
>  > mattered.  Harold has not weighed in on that counter proposal yet.
> 
> HB> Indeed, using the Prolog-like notation s/a for an s of arity a,
> HB> s/n{1->t_1, …, i->t_i, …, n->t_n} doesn’t unify s/i{1->t_1, …, i->t_i}
> HB> and with this ‘locally-closed-slot’ semantics imposed by s/n and s/i
> HB> s/n(t_1, …, t_i, …, t_n) would no longer unify s/i(t_1, …, t_i).
> 
> I hope the above explanation will help.
> 
>  > Michael expressed some concern that the CLP formulation would not handle
>  > model theories for WFS. (was that right?)  Hassan was unsure and will
>  > try to find the answer.
> 
> I have to communicate off line with Michael about that.
> 
>  > We discussed for a while the idea of treating constraints as an
>  > "external call".  This seemed to concern several of us, but I think the
>  > confusion was cleared up as just overloading of "external call" - here
>  > the idea is that constraints as part of RIF rules allows RIF to treat
>  > data models and languages as orthogonal.
> 
> Yes. This is the essence of it.
> 
> Thanks for your summary.
> 
> -hak
> --
> Hassan Aït-Kaci
> ILOG, Inc. - Product Division R&D
> tel/fax: +1 (604) 930-5603 - email: hak @ ilog . com
> 

-- 
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 Tuesday, 2 January 2007 15:32:43 UTC