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)

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