From: Chris Welty <cawelty@gmail.com>

Date: Tue, 02 Jan 2007 10:32:08 -0500

Message-ID: <459A7AF8.7000207@gmail.com>

To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>

CC: Hassan Aït-Kaci <hak@ilog.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Date: Tue, 02 Jan 2007 10:32:08 -0500

Message-ID: <459A7AF8.7000207@gmail.com>

To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>

CC: Hassan Aït-Kaci <hak@ilog.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

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 wouldnt 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} doesnt 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/weltyReceived on Tuesday, 2 January 2007 15:32:43 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:47:41 UTC
*