RIF Telecon 19 June 2007 -- 19 Jun 2007

csma: next meeting 26th June

<sandro> scribe: StellaMitchell

csma: action 316 has been done, but I will keep it open until Adrian updates the minutes

<csma> action-316 continued

csma: any ammendments? ... none
... PROPOSED: accept minutes of June 12th
... no objections

RESOLUTION: accept June 12 minutes

csma: any news from liasons?
... none of them are here today
... sent regrets
... next week all OMG liasons will be at OMG meeting
... today was the deadline for proposals for F2F7
... we had no proposals

Harold: wanted to propose one, but didn't get approval yet
... I should know by Monday

<sandro> ,+NB,+Canada&ie=UTF8&ll=45.95115,-66.621094&spn=40.97359,65.654297&z=4&iwloc=addr&om=1 Fredericton (Harold's site)

csma: new dealine for proposals is Monday

June 25

<scribe> ACTION: christian to send reminder for f2f proposals [recorded in http://www.w3.org/2007/06/19-rif-minutes.html#action01]

<rifbot> Created ACTION-317 - Send reminder for f2f proposals [on Christian de Sainte Marie - due 2007-06-26].

Technical design

csma: action review
... need to do something about action-142 on Hassan
... either obsolete or close

<Hassan> This is conyinued ad lib

sandro: let's close

<Hassan> This is continued ad lib

<Hassan> ok

action-142 closed

actions 152 157 159 160

csma: it would be useful to have the above actions completed

csma; Leora, Gary, can you commit to dates for these actions?

Leora: I did propse a few examples in the fall; I can revisit them. When do you want them by?

csma: as early as possible to discuss a few representative examples

Leora: how about June 29th?

csma: Gary?

Gary: I can by June 22nd, UC9

sandro: I updated due dates in tracker

csma: action on harold about condition library, date is in august
... action-255 continued
... action-25? on csma continuted

<josb> done

csma: action-258 on daver continuted

<josb> yes

<josb> OK

sandro: we have to talk about all these actions before we close them

<josb> yes

<sandro> (Maybe we can get an alternate action-state in tracker.)

csma: do you think it's a good idea to discuss RDF and data sets next week?

<DaveReynolds> OK by me

<DaveReynolds> Yes, should be there

<josb> not yet sure

<sandro> Jos -- at risk in one week (along with csma), but will be available in two weeks.

csma: we will discuss it the week after, June 29th

<sandro> (for talking about RDF)

action-294 done

csma: Gary's action from F2F on top few difficulties in mapping to xml schema

gary: I don't have any difficulties

sandro: let's close that action for now

jos: I raised point about use of xml schema as data model; wondering how it would be done?
... I think mapping is useful (not just pain points)

<sandro> "Show how to use XML Schema for App Data Model"

sandro: can we rephrase action as above?

gary: I thought action had to do with mapping of ASN to schema

<sandro> Gary: I thought this was about mapping abstract syntax into XML Schema

<sandro> (ACTION-298)

csma: gary, can we rephrase the actionas above, and will you accept it?

gary: I will accept it, but can't do it until after first week of july
... by July 13th

csma: action on sandro about abstract syntax.

sandro: continued. change due date to July 6th

action-307 continued

<Harold> DaveR and JosB, could we clarify our action with MichaelK in offline email exchange?

<DaveReynolds> Harold: sure, my memory is that I just offered to help on the abstract syntax but if you have it in hand already I'm happy to not interfere

<Harold> Dave, please give your input.

AOB

<ChrisW> Chair: Christian de Sainte-Marie

Technical design

harold: as I my email, 2 possibilities:
... 1. nested pairs
... 2. direct n-ary sequences
... I sent a recent email with answers to sandro's questions
... daver had sent an alternative where we treat them more like frames/objects

csma: what are we trying to achieve with lists?
... I thought we wanted to have lists as a type, but you seem to be talking about building and manipulating lists
... i thought we would just declare a type, and some builtins to go with it
... constants?

harold: (??)

csma: why can't we take rdf lists or rdf containers from rdf schema (and associated builtins)?

<sandro> harold: it's about whether lists are terms or objects

<sandro> harold: F-Logic is not meant to do unificaiton over frames.

daver: there are 3 approaches we could take:

<sandro> (sure, Stella. I like to write down for myself anything I really really want to remember)

daver: 1. build primitive types
... 2. use e.g. RDF types
... 3. frame/object structures

<Harold> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0035.html

harold: re: why we can't unify across.... see the above email

<sandro> LISP has lists-as-objects as well, property-lists. The more functional-programming style is the term-style.

daver: why can't you unify over nested structures

harold: nesting is called molecule in f-logic, only one property per atom

<sandro> Harold: When you have a molecule, you split it into f-logic atoms. To match across those, across multiple rules, to me that's not unification.

<sandro> Harold: (1) un-nesting, then (2) atomizing. _:1[rdf:first->a] & _:1[rdf:rest->_:2] & _:2[...] & ...

<josb> +1

<sandro> Harold: Yes, Sandro, in one flavor of f-logic, there are anonymous terms, often written with underscore.

harold: anonymous oids are allowed in in one flavor of f-logic

hassan: why do we care so much about f-logic?

<Harold> Hassan, we agreed to have 'frames'.

sandro: my impression is that this (f-logic) was put forward at f2f as how to handle slots

<Harold> You can see them as 'feature terms'.

hassan: I don't remember that

<Harold> ... or 'psi terms'.

<sandro> Sandro: we agreed on "frames" not on "f-logic".

<sandro> Sandro: I sort of assumed they were the same.

<sandro> Hassan: they are not!

hassan: several formalisms have been proposed, but we haven't agreed yet on the nature of objects we are reprsenting
... I don't think we all agreed to f-logic as a way to represent frames yet

<DaveReynolds> +1 to Hassan - using the proposed frame representation does not correspond to accepting all of f-logic

csma: the current topic is lists

<sandro> Hassan, do you take this logic to be your lawfully wedded logic, to have and to hold, to love and cherish, until disjunction do you part? :-)

csma: we are not debating f-logic

hassan: .. disagrees

csma: we are focusing on lists in the current discussion

<sandro> Hassan: Free Algebra with two constructors

<Harold> In F2F6, "frames" of http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions were accepted.

csma: so, you propose that we have an abstract concept with 3 builtins

<sandro> Hassan, are you saying we should have the primitives First/Rest/Nil or the primitives Cons (or pair) and Nil ?

jos: I agree with Hassan that we don't need to mention f-logic, and just talk about the constructs proposed for RIF, such as the frame syntax

<Harold> Look at "The Unnest Transformation"

csma: we did not discuss yet, what is the meaning of frames. we just agreed that we would have them
... why isn't what hassan suggests above (abstract type and 3 builtins) sufficient?

harold: that is similar to my first option

csma: does that proposal (harold's first) require a change to ASN

harold: yes, but not to the semantics

csma: why do we need to change ASN for list type, when we don't have to change it for any other type

harold: const vs. terms?

<sandro> Harold: because those are simple types; List is a compound type, which contains elements of other types.

hassan: aren't lists special cases of uniterms?

harold: yes

<Harold> Uniterm ::= Const '(' TERM* ')'

csma: what is the diff in operations between list (various types) and strings (only chars)

<sandro> Harold: you can have variables inside a List, but not inside a string.

<sandro> Harold: We certainly want to do list unifications in Core.

csma: is there a consensus that we need support for variables inside lists?
... i.e. do lists need to be terms

<josb> +1 to variables in lists

<sandro> +1 variables in lists

<sandro> csma: sounds like consensus that we need to support variables in lists -- quite different from primiitve data types.

csma: now, regarding the form - is there a preferred way to represent this?

<Hassan> +1 with sandro

sandro: to me, a term denotes an object, I don't fully get the distiction that harold makes between the two

<sandro> Sandro: to me a term denotes an object, so first(pair(a,b), a)

<Hassan> Lists are objects - frame vs. term syntax is just that: SYNTAX

<sandro> -1 to anyone saying "RIF is an interchange format" :-)

harold: in rif, we have an opportunity to bring them together

<josb> please distinguish object vs object ID

<josb> object ID = ground term

csma: I would like to have a sense of what lists will look like
... we have a few proposals, some people say they are not all equivalent

sandro: I would like to harold's comments on dave's email

harold: dave's in an object style
... if have anonymous oid, the two proposals are not so different

<Hassan> The simplest common denominator is syntax - in the sense that a syntactic (initial or final) algebra is also a model in the category of all models

<sandro> Harold: if the frames are anonymous, than Dave's form is pretty much the same -- the objects are then just terms.

daver: I'm not trying to form a new proposal: I was trying to see how Harold's proposal matches up to RDF lists
... i.e. how we can map
... was trying to combine our representation of blank nodes with frames proposal from last f2f

sandro: I think users would like to have all forms of lists available and know that they are all the same things

<Harold> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0052.html

.csma: why is it more important to have logical variables in lists than to have them in other builtins on primitive datatypes

harold: because the others ones are kind of atomic

sandro: I think csma is saying, e.g. why can't we do 3 = 4 + x

<josb> why was this excluded? We can simply have binding patterns for built-ins

hassan: the difference is: there are 2 kinds of terms - constructed (syntactic) and interpreted (semantic)

<sandro> Hassan: constructed terms vs unified terms. constructed terms can be uniifed against.

hassan: first can be unified against, second can not

csma: ok

<Harold> As Hassan mentions you cannot unify ?X+1 with 9 and bind ?X to 8.

hassan: this brings up another question: in prolog or lisp you can quote things

(to make it syntactic)

scribe: do we want to do that in RIF?

csma: back to topic: we have 2 proposed syntaxes from Harold

<GaryHallmark> +1 for List, -1 for Pair

harold: list type is a bit more advanced

<sandro> Harold: We want pair underneath List, if we have List.

<Harold> But there is a point with 'invertible arithmetics' being not allowed, but 'invertible list processing' being allowed.

<Hassan> +1 for pairs

<josb> can we have a link to the proposals?

<Francois> +1 for pairs

<sandro> Sandro: I understood List to be built on top of pair, so if you have List you also have Pair.

<sandro> Dave: I List *just* syntactic sugar? I understood Harold to say yes.

harold: first one above is more than syntactic sugar
... most systems to introduce a new tag though

<sandro> Harold: Most systems introduce a special syntax for Pair.

sandro: can we agree to use pair as underlying semantics for lists

<sandro> Sandro: it sounds like maybe there's consensus that we use Pair/Nil for the underlying semantic of lists, and we figure out List and rdf-interoperation (first/rest) afterwords.

csma: if we need in future, sets, bags, etc - will those be new constructors also

<ChrisW> isn't pair/nil the same as rdf?

<Hassan> list cons is an Assoc. constructor; set cons is an Accoc. Comm. Idemptotent constructor

<sandro> No, ChrisW RDF uses first+rest, not pair. that is, every list in RDF is an object, possibly with other properties.

harold: in 1st above, we introduce a new type. in 2nd above, we don't

<ChrisW> i don't see the difference (rdf vs pair)

jos: we keep using term "pair" but it's a strange name to me - I think we should call it "list"

<sandro> Sandro: the traditional name is "cons" right?

<Francois> +1 with Jos.

<ChrisW> the traditional name is "cons cell"

<sandro> written as "." sometimes.

<GaryHallmark> cons seems too implementation oriented

<Francois> cons is a binary operation, hence it has 2 args, hence the notion of pair arises.

<Francois> +1 with Hassan : it is CS 1.

<ChrisW> more than 30!

hassan: we are debating well established concepts, I don't think we should do this

<Francois> Lisp goes back to 1950 and Lisp hs ... lists. It is more than 30 years.

<ChrisW> i take that was a "no"

csma: if it's simple and there is consensus, can you write it down in form to go into the specification?

hassan: no

<Francois> Sandro, a better name than "pair" is "list constructor" from which "cons" is derived.

<Francois> Do we have an object concept in RIF Core?

csma: consensus that it is a term not an object?

<josb> +1 to Francois' proposal

sandro: yes, I think so

<Francois> no consensus on term not object. RIF has no object notion so far.

<Harold> Francois, yes we have a frame concept with oid (see above).

<Francois> frame is not object. Sorry.

<josb> List alone is also fine

<Francois> Frame in RIF is pure syntax, not OO.

<DaveReynolds> These will all be IRIs anyway ...

<josb> we only have 2-item lists

<Hassan> what???

sandro: we are talking about 2 item list, not the arbitrary lenghth one

<GaryHallmark> harold's list proposal is n-ary

<Hassan> Sandor what R U talking about???

<Francois> Sandor, no infinite list, ie no arbitrary length lists.

sandro: re: names
... as an operator in the concrete syntax

<Harold> Gary, we could have binary <List> vs. n-ary <Tup>.

<Francois> I think "list" has reach a similar status as "sort"... :-)

<GaryHallmark> I like n-ary, like the last example in your last email, Harold

csma: we will discuss this again next telecon. we need to draft a proposal

<Harold> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0032.html

<sandro> Sandro: The problem with calling "cons" "list" is that we will also want (as Harold said) the List syntactic sugar. (as in LISP, which has both cost and list, right? am I remembering that right?)

<sandro> GaryHallmark, the problem with n-ary is how you do a variable tail.

<DaveReynolds> Again, the name in the abstract syntax will be an IRI

harold: I didn't do abstract syntax in my email, but in the abstract we don't need to distinguish (between 2, and n-ary)

<Francois> Sandro, you get a list tail from a "n-ary" list notation provided you ghave a constructor for this.

<sandro> csma: use "List Constructor" for pair for now.

<ChrisW> a "cons" by any other name would still have a "cdr"

csma: harold will post proposal in abstract syntax
... we had a proposed resolution (re: builtins)

<csma> http://www.w3.org/2005/rules/wg/wiki/List_of_functions_and_operators?action=recall&rev=7

<DaveReynolds> opposed: see http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0050.html

<Francois> bye, sorry I must leave.

<josb> objection

<DaveReynolds> sorry :-)

csma: several objections..

jos: I haven't read it carefully enough to be able to agree at this time

csma: we will discuss it later then

AOB

<DaveReynolds> +1

<sandro> +1 adjourn :-)

<ChrisWelty> sandro?

- DRAFT -

RIF Telecon 19 June 2007

19 Jun 2007

Attendees

Contents

Technical design

AOB

Technical design

AOB

Summary of Action Items

Scribe.perl diagnostic output