See also: IRC log
<ChrisW> Minutes of Jan 8 Telecon
<ChrisW> RESOLVED: Accept Jan 8 Telecon minutes
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
<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
<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)
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
... 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?
<AxelPolleres> +1 for reasons mentioned in the last telecon, I favor keeping BLD general and we have a clean definition of these already
<ChrisW> Who favors removing named-argument uniterms?
<csma> PROPOSED: BLD WD2 will include the builtins listed in  (functions on numerics),  (functions on strings) and  (functions on dates and times)
<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
... 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!
<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
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
chrisw: the issue is about lists
<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)
<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) ) ) )
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
sandro: new wiki can allow wiki editing and html editing