W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2008

Re: regrets telecon on Tuesday

From: Hassan At-Kaci <hak@ilog.com>
Date: Mon, 21 Jan 2008 17:40:35 +0100
Message-ID: <4794CB03.7020006@ilog.com>
To: axel@polleres.net
CC: Christian de Sainte Marie <csma@ilog.fr>, Jos de Bruijn <debruijn@inf.unibz.it>, RIF <public-rif-wg@w3.org>

Axel Polleres wrote:

> whereas, on the contrary in frames, any slot can appear 0 or several 
> times, i.e.
> person1[firstname -> "Christian", lastname -> "de Sainte Marie"]
> and
> person1[firstname -> "Christian"] AND person1[lastname -> "de Sainte 
> Marie"]
> say the exactly same thing, i.e. mutually entail each other.

What? You mean that there can be only one "person1" object named
"Christian"? IMHO, what you are describing corresponds to the notion
of database record key(s) - i.e., the attribute(s) that characterize
individual records.

Furthermore, even if you do have a notion of keys (which we have
not discussed within RIF as far as I recall), there is still another
situation to take into consideration: just like algebraic (i.e.,
positional) terms are built of symbols that may have (or not)
well-formedness constraints (e.g., signatures, typing, annotations,
etc...). To make things even more interesting, not everyone agrees
with one specific semantics for the very same frame syntax (i.e., do
we allow repeated "slots" - and in this case, is this an error or is
it that such a slot has as value the set (or some kind of aggregate)
of all the values for this slot. Some also allow mandatory as well
as non-mandatory attributes - some even allow any symbol as a slot
(i.e., unconstrained signatures).

While the RIF BLD masterminds (i.e., the authors of the document:
Harold and Michael) give one possible semantics for these syntactic
constructs; but this semantics is not necessarily compatible with
many extant rule languages, several of which would wish to use the RIF.

Hassan At-Kaci  *  ILOG, Inc. - Product Division R&D
Received on Monday, 21 January 2008 16:42:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:49 UTC