See also: IRC log
Christian: Next meeting, 26th June
Christian: Action 316 has been done, but I will keep it open until Adrian updates the minutes from May 22
<csma> action-316 continued
Christian: Any ammendments? ... none
Christian: PROPOSED: accept minutes of June 12th... no objections
RESOLUTION: accept June 12 minutes
Christian: Any news from liasons? None of them are here today, they sent regrets
.. next week all OMG liasons will be at an OMG meeting
Christian: Today was the deadline for proposals for F2F7.. we had no proposals
Harold: I wanted to make a proposal, but didn't get internal approval yet. I should know by Monday
Christian: New deadline 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].
Christian: We need to do something about action-142 on Hassan; either obsolete it or close it
Sandro: Let's close
<Hassan> This is continued ad lib
<Hassan> ok
action-142 closed
Christian: It would be useful to have action-152, action-157, action-159 and action-160 completed
Christian: Leora (action-159), Gary (action-157), can you commit to dates for yours?
Leora: I did propose a few examples in the fall; I can revisit them. When do you want them by?
Christian: As early as possible so we can discuss a few representative examples
Leora: How about June 29th?
Gary: I can by June 22nd, for UC9
Sandro: I updated the due dates in the tracker
Christian: Action-253 on Harold about condition library is due in August
action-255 on Sandro continued
action-256 on Christian continued
action-258 on Dave Reynolds continued
<josb> done
<josb> yes
<josb> OK
Sandro: We have to talk about all these actions before we close them
<sandro> (Maybe we can get an alternate action-state in tracker.)
Christian: All, 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.
Christian: We will discuss RDF and data sets in two weeks
action-294 done
Christian: Gary had action-298 from F2F6 on describing the top few difficulties in mapping to XML schema
Gary: I don't have any difficulties
Sandro: Let's close that action for now
JosB: Re: that action-298, I raised the point about the use of
XML schema as a data model; I was wondering how it would be done?
... I think a mapping (not just the pain points) would be useful
<sandro> "Show how to use XML Schema for App Data Model"
Sandro: Can we rephrase action as above?
Gary: I thought the action had to do with mapping of ASN to XML Schema
Christian: Gary, can we rephrase your action-298 as Sandro typed above, and will you accept it?
Gary: I will accept it, but can't work on it until after the first week of July, so say by July 13th
Christian: Action-307 on Sandro about his suggestions for abstract syntax.
Sandro: action-307 continued. I changed the due date to July 6th
<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.
Harold: I described two possibilities in my email about lists in core:
........ 1. nested pairs
........ 2. direct n-ary sequences
... Also, I sent a recent answer to Sandro's questions about striping in XML
... Also, Dave Reynolds had sent an answer to my original email, where he discussed the mapping to frames/objects
Christian: 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 built-ins
to go with it
... constants?
Christian: Why can't we just take RDF lists or RDF containers, along with the associated built-ins, from RDF schema?
<sandro> harold: it's about whether lists are terms or objects
<sandro> harold: F-Logic is not meant to do unification over frames.
Dave Reynolds: There are 3 approaches we
could take:
... 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 frames... see the above email
<sandro> LISP has lists-as-objects as well, property-lists. The more functional-programming style is the term-style.
Dave Reynolds: Why can't you unify over nested structures?
Harold: A frame is called a molecule in F-logic. Each atom can have only one property
<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 (object ids) are allowed in one flavor of F-logic
Hassan: Why are we talking so much, and being concerned so much, about F-logic??
<Harold> Hassan, we agreed to have 'frames'.
<Harold> You can see them as 'feature terms'.
<Harold> ... or 'psi terms'.
Sandro: My impression is that this (F-logic) was put forward at F2F6 as how we would handle slots
Hassan: I don't remember that. I didn't agree to marry F-logic!
<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 yet agreed on the nature of
the objects we are representing
... I don't think we have all agreed to F-logic as a way to
represent frames
<DaveReynolds> +1 to Hassan - using the proposed frame representation does not correspond to accepting all of f-logic
<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? :-)
<Harold> In F2F6, "frames" of http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions were accepted.
Christian: The current topic is lists. We are not debating F-logic
Hassan: (disagrees)
Christian: We are focusing on lists in the current discussion
<sandro> Hassan: Free Algebra with two constructors
Christian: So, you propose that we have an abstract concept (type) with 3 built-ins?
<sandro> Hassan, are you saying we should have the primitives First/Rest/Nil or the primitives Cons (or pair) and Nil ?
JosB: I agree with Hassan that we don't need to mention F-logic, and we should just talk about the constructs proposed for RIF, such as the frame syntax
<Harold> Look at "The Unnest Transformation"
Christian: We did not yet discuss 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 built-ins) sufficient?
Harold: That is similar to my first option
Christian: Does that proposal (Harold's first option) require a change to the ASN?
Harold: Yes, but not to the semantics
Christian: Why do we need to change the ASN for list type, when we don't have to change it for any other type?
<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* ')'
Christian: What is the difference in operations between list (arbitrary 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.
Christian: 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.
Christian: 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 distinction 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 (Psi-terms and relational slots?) together
<josb> please distinguish object vs object ID
<josb> object ID = ground term
Christian: 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 hear Harold's comments on Dave Reynold's email
Harold: Dave's is an object style. If you have anonymous oids (object ids), the two proposals are not so different
<sandro> Harold: if the frames are anonymous, than Dave's form is pretty much the same -- the objects are then just terms.
<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
Dave Reynolds: 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 do the mapping
... I was trying to combine our representation of blank nodes
with the frames proposal from F2F6
Sandro: I think users would like to have all forms of lists available and know that they are all the same things
Christian: why is it more important to have logical variables in lists than to have them in other built-ins that operate on primitive datatypes?
Harold: Because the others ones are kind of atomic
Sandro: I think Christian is saying, e.g. why can't we do 3 = 4 + x?
Hassan: The difference is: there are two kinds of terms - 1.constructed (syntactic) and 2.interpreted (semantic). The first can be unified against, the second cannot
<sandro> Hassan: constructed terms vs unified terms. constructed terms can be unified against.
Christian: OK
<josb> why was this excluded? We can simply have binding patterns for built-ins
<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 them syntactic (i.e. prevent interpretation). Do we want to do that in RIF?
Christian: Back to topic: we have two proposed syntaxes from Harold
<GaryHallmark> +1 for List, -1 for Pair
Harold: The 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?
Harold's proposals for lists in core
<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: Is List *just* syntactic sugar? I understood Harold to say yes.
<Harold> <Pair>
<Harold> <Const>Pair</Const>
Harold: The first of the two options that I posted in the IRC above is more than syntactic sugar. However, most systems introduce a new tag.
<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.
<ChrisW> isn't pair/nil the same as rdf?
<sandro> No, ChrisW RDF uses first+rest, not pair. that is, every list in RDF is an object, possibly with other properties.
<ChrisW> i don't see the difference (rdf vs pair)
Christian: In the future, if we need other aggregates like sets, bags, etc, will those be new constructors also?
<Hassan> list cons is an Assoc. constructor; set cons is an Accoc. Comm. Idemptotent constructor
<Harold> <Pair> a' b' </Pair> vs. <Uniterm> <Const>Pair</Const> a' b' </Uniterm>
Harold: In 1st above, we introduce a new type. in 2nd above, we don't
JosB: We keep using the term "pair" but it seems like an inappropriate name to me - I think we should call it "list"
<sandro> Sandro: the traditional name is "cons" right?
<sandro> written as "." sometimes.
<Francois> +1 with Jos.
<ChrisW> the traditional name is "cons cell"
<Harold> Jos: <List> a' b' </List> vs. <Uniterm> <Const>List</Const> a' b' </Uniterm>
<GaryHallmark> cons seems too implementation oriented
<Francois> cons is a binary operation, hence it has 2 args, hence the notion of pair arises.
Hassan: We are debating well established concepts, and I don't think we should spend time doing this. Lists go back 30 years.
<Francois> +1 with Hassan : it is CS 101.
<ChrisW> more than 30!
<Francois> Lisp goes back to 1950 and Lisp has ... lists. It is more than 30 years.
Christian: Hassan, if it's simple and there is consensus, will you take an action to write it down in a form to go into the core specification?
<ChrisW> i take that was a "no"
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?
<josb> +1 to Francois' proposal
Christian: Is there consensus that it is a term and not an object?
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.
<Francois> Frame in RIF is pure syntax, not OO.
<josb> List alone is also fine
<DaveReynolds> These will all be IRIs anyway ...
<josb> we only have 2-item lists
<Hassan> what???
Sandro: We are talking about 2-item lists, not arbitrary length ones
<GaryHallmark> harold's list proposal is n-ary
<Hassan> Sandro what R U talking about???
<Francois> Sandro, no infinite list, ie no arbitrary length lists.
Sandro: Regarding names - I was talking about operators in the concrete XML 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
Christian: 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 give an abstract syntax in my email. In the abstract syntax, we will not need to distinguish between 2-item lists, and n-ary lists
<Francois> Sandro, you get a list tail from a "n-ary" list notation provided you have 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"
Christian: Harold will post the abstract syntax for his proposal
Christian: The agenda included a proposal regarding built-ins. It is proposed that we include exactly these built-ins in the core
<DaveReynolds> opposed: see http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0050.html
<DaveReynolds> sorry :-)
<Francois> bye, sorry I must leave.
<josb> objection
Christian: There are several objections..
JosB: I haven't read it carefully enough to be able to agree at this time
Christian: We will discuss further at a future telecon then.
Christian: Propose to adjourn
<DaveReynolds> +1
<sandro> +1 adjourn :-)