admin

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jan/att-0028/rif-minutes-jan8-2008.html

<ChrisW> Minutes of Jan 8 Telecon

<ChrisW> RESOLVED: Accept Jan 8 Telecon minutes

Liason

josb: owl DL and owl Full have incompatible RIF mappings

<Harold> Did the OWL WG look into the RIF builtin proposal?

harold: RIF uses functions as operators, what does owl do?

josb: mathML is being discussed, more on Friday

Issue 47

<csma> PROPOSED: to close issue 47 without action (i.e. equality stays in BLD as it is currently specified)

chrisw: last week, nobody objected

<DaveReynolds> I'll abstain

<Hassan> me

<csma> RESOLVED: to close issue 47 without action (i.e. equality stays in BLD as it is currently specified)

<ChrisW> Abstentions: Hassan (Ilog), DaveR (HP)

Issue-44

harold: relational tables map naturally to slotted uniterms

csma: could just agree on position out of band
... in slotted case, need to agree on table and column names anyway

harold: such a "schema" of DB is needed, but is a different issue

csma: do not need slotted uniterms to avoid OIDs

harold: slot names are self-descriptive
... if frames need slots, why not uniterms?
... slotted uniterms implemented in ojdrew

sandro: any relation of frames to bnodes?

josb: skolemize blank nodes
... but embedding relations is different from RDF

sandro: embedding relational DB in RDF is common
... should be able to use frames for RDF and relational data

mark: need anonymous or local OID

csma: RIF does not specify an OID format

mark: rule engines don't generate the OID until fact is inserted into engine

<AxelPolleres> Is that relating to set- vs multiset-semantics? i.e. two uniterms with different generated oids are different things (objects), but not if you just see the uniterm... our logical semantics is obviously set-based

<AxelPolleres> jos, I think the discussion is whether we need slotted uniterms, or whether they can (in *any* case) be emulated with oids?

josb: tuple is self-identifying -- doesn't matter if you use names or positions
... reiterates csma's point

harold: Codd's intent of "tuple" seems to include slots

<josb> columns, not rows!!!!

<josb> not frames, uniterms!!!

chrisw: does converting to frames do anything bad?

axel: tuples can appear > 1 (multiset)

josb: pure relational is set based, SQL is multiset

axel: need OIDs anyway to handle duplicate tuples

harold: what about positional frames?

<AxelPolleres> +1 to what you said now, harold. I didn't speak againt named uniterms.

harold: slots and OIDs are independent, so 4 combinations

<AxelPolleres> ... only against the use case relational databases. Agree, that this is ugly in RDBMS

csma: RIF not meant to interchange DBs

harold: but we are close to datalog and should be useful for such interchange

chrisw: straw poll

<ChrisW> Who favors keeping named-argument uniterms?

<Gary> -1

<Harold> +1

<Hassan> 0

<josb> -1

<IgorMozetic> +1

<PaulaP> 0

<AxelPolleres> +1 for reasons mentioned in the last telecon, I favor keeping BLD general and we have a clean definition of these already

<StellaMitchell> +1

<sandro> +1

<ChrisW> Who favors removing named-argument uniterms?

<josb> +1

<csma> +1

<IgorMozetic> -1

<sandro> 0

<Gary> +1

<AxelPolleres> -1

<DaveReynolds> +1

<Hassan> 0

<PaulaP> 0

<StellaMitchell> 0

<Harold> 0

Builtins

<csma> PROPOSED: BLD WD2 will include the builtins listed in [6] (functions on numerics), [7] (functions on strings) and [8] (functions on dates and times)

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jan/0073.html

<csma> PROPOSED: BLD WD2 will include the builtins listed in http://lists.w3.org/Archives/Public/public-rif-wg/2008Jan/0073.html

<Hassan> I agree

<PaulaP> this list is for BLD, we didn't discuss this issue for Core

dave: status of builtin functions vs. predicates?

<sandro> Sandro: are external calls excluded from core (as Dave seems to be assuming) ?

dave: don't we need predicates if we don't have equality (talking about Core)
... functions w/o equality makes it hard to return a computed value in an answer

<Harold> Sandro, I dont remember a decision; I think we do need external calls (builtins, fcts or preds) in the Core.

csma: PRD prefers builtin fcns over preds

<PaulaP> we have functions and operators in the list

<sandro> Harold, I agree we want builtins --- I'm just not sure if they might be function-style.

<Harold> Well, only today we decided to keep equality...

<Harold> ... which is needed to call function-style.

<AxelPolleres> add(X,Y,Z) it wouldn't bind a value to Z, but it would have aa fixed interpretation which allows only one value for Z if X and Y are bound.

<AxelPolleres> ... slight difference.

dave: w/o equality in Core, functional style builtins are less useful than predicate style

<Harold> Equality with builtin calls on right-hand side corresponds to Prolog's "is" primitive.

dave: what about list types?
... need to agree on specifics of the list type for next draft
... need to specify collation

<PaulaP> e.g contains

dave: e.g. compare builtin
... minimum is simple codepoint collation
... or just omit colation sensitive builtins altogether

josb: can't decide on list of builtins before deciding on functional vs. predicate style

<csma> Arghhh! The proposed resolution has been implicitely or explicitely on the table for a long long time!

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins

<scribe> ACTION: dreynold2 to add collation issue to builtins wiki page [recorded in http://www.w3.org/2008/01/15-rif-minutes.html#action04]

<trackbot-ng> Created ACTION-400 - Add collation issue to builtins wiki page [on Dave Reynolds - due 2008-01-22].

josb: also need to define semantics of builtins
... before we can evaluate the proposed list of builtins

<AxelPolleres> I think, so far, we only have sketched/discussed the semantics for built-on *predicates*, AFAIK

josb: model theoretic RIF semantics w.r.t. builtins

<csma> ExtTerm

josb: need semantics of "ExtTerm"

<AxelPolleres> We diden't fix how ExtTerms look like though (BTW), did we? We just said we want them to be syntacticcally distinguisheable

chrisw: same semantics as "Term"

josb: but there are outstanding issues w.r.t. Error handling

<Harold> We seem not to know yet if Equality should be allowed both in BLD and in Core, but I think we will need builtins in Core. So in order to allow the more natural functional builtins in Core we should allow (restricted) Equality there.

<AxelPolleres> +1 to jos, nothing to add, we need to have the semantics of built-in preds and functions on the table, then we can discuss it. Agree that it should be straightfwd for most predicates, not sure about functions at the moment, but hopefully similar

chrisw: not ready for resolution

Issue 45

chrisw: the issue is about lists

<Harold> http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor

<DougL> I think we should have both, don't you think?

<josb> -1 to have both

<AxelPolleres> as for the tagnames, should we use ones more similar to the resp. rdf vocabulary, i.e. List, first, rest, nil instead of Pair

harold: alternatives are pairs vs. n-ary sequences
... n-ary sequences are more common

<DougL> I meant for conceptual impedance matching, allowing both, not saving a few bits. What is the COST of allowing both?

<AxelPolleres> rdf doesn't have seq ... prolog doesn't have seq

chrisw: anyone really want pairs?

<AxelPolleres> they use the pair stuff, but Prolog has syntactic sugar for something which looks like seqs.

<Harold> Axel, prolog has seq's [e1, e2, ..., eN].

<AxelPolleres> I see the point with the blowup in the xml though...

chrisw: pairs take a lot of space to represent in xml

<DougL> These are arguments for allowing sequences; they are not arguments for NOT having pairs as well.

hassan: not completely equivalent in non-ground case

josb: use pairs in language defn, sequences in xml

<DaveReynolds> +1 to Jos

chrisw: straw poll on Jos's statement

<DougL> +2 Jos then

<DougL> (+2 means: I not only agree, I wish I had said that)

<DaveReynolds> +1

<DougL> +1

<Hassan> +1

<josb> +1

<PaulaP> +1

<Harold> +1

<IgorMozetic> 0

<sandro> +1

<AxelPolleres> 0 why have syntactic sugar in the XML and not in the presentation syntax?

<josb> axel: sequences cannot be incomplete, as Hassan mentioned

axel: but language defn should be readable, therefore use sequences

axel: don't read xml, don't care about xml syntax

<IgorMozetic> +1 for Axel

<josb> fine with me as well

<Hassan> fine here too

axel: semantics uses pairs, presentation syntax and xml syntax uses sequences
... prefer 1b for semantics, 1a for syntax

axel: 1a, 1b from http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor

<josb> Seq ( a ?Y c | ?R) as shortcut?

chrisw: let's resolve next week

<AxelPolleres> jos? didn't get your example.

<AxelPolleres> ... what does the pipe there?

<josb> we need to distinguish between last element and tail

<josb> after | is the tail (see bottom of page)

<AxelPolleres> I wouldn't allow '|' in Seq

<AxelPolleres> but use Seq ( a b c) as a shortcut for rif:list( rif:frst (a) rif:rest( rif:list(rif:irst(b) rif:rest( rif:List( rif:first(c) rif:rest(rif:nil) ) ) )

AOB

harold: which wiki are we supposed to use?

<ChrisW> Paula, can you scribe next week?

sandro: wants feedback on conversion of docs to new wiki

<PaulaP> bye

<ChrisW> paula

sandro: new wiki can allow wiki editing and html editing