From: Gary Hallmark <gary.hallmark@oracle.com>

Date: Tue, 31 Mar 2009 13:10:07 -0700

Message-ID: <499257640903311310s7469aac8pd23460537456804d@mail.gmail.com>

To: kifer@cs.sunysb.edu

Cc: Christian de Sainte Marie <csma@ilog.fr>, public-rif-wg@w3.org

Date: Tue, 31 Mar 2009 13:10:07 -0700

Message-ID: <499257640903311310s7469aac8pd23460537456804d@mail.gmail.com>

To: kifer@cs.sunysb.edu

Cc: Christian de Sainte Marie <csma@ilog.fr>, public-rif-wg@w3.org

On Tue, Mar 31, 2009 at 10:42 AM, Michael Kifer <kifer@cs.sunysb.edu> wrote: > > > On Mon, 30 Mar 2009 23:21:40 -0700 > Gary Hallmark <gary.hallmark@oracle.com> wrote: > >> example of my proposal: >> >> the statement "class eg:MyClass [ eg:att_1->xs:string, >> eg:att_2->set(xs:date) ] " > > Garry, I don't understand the above syntax. it says that objects belonging to MyClass have a single-valued slot of type string and a multi-valued slot of type date. > >> means >> (BLD) >> Forall ?o, ?x, ?y, ?z If ?o#eg:MyClass AND ?o[eg:att_1 -> ?x eg:att_1 -> >> ?y eg:att_2 -> ?z] >> Then ?x = ?y AND pred:isString(?x) AND pred:isDate(?z) > > Can't understand the above either. How are ?y and ?z related? It makes no sense > for ?y to appear only in the conclusion. But ?y appears in the frame formula in the premise. Perhaps an unfortunate linebreak ending in -> threw you off? The keyword "Then" introduces the conclusion (which comes after the premise here) Also, pred:isString(?x) AND > pred:isDate(?z) don't make sense to me. Basically, the above says that every y equals x (which is defined by att_1) and every such x and z is a string/date. I think it says that if an object ?o is a member of MyClass and has a slot att_1 with 2 values ?x and ?y, then those values must be the same. Furthermore, the type of att_1 is string and the type of att_2 is date. If not the case, then the rule is inconsistent. > What if I have a fact like > > ...[att_1-> 1, att_2->2]. > > Then the above rule is inconsistent. Yes, exactly. You have violated the datatype constraint implied by the class statement. > Also, builtin predicates are not allowed in rule heads. Well, it seems we now have a use case for allowing them. Unless you have another suggestion for expressing such datatype constraints in BLD? > > michael > > >> >> (PRD) >> Forall ?o, ?x, ?y If ?o#eg:MyClass AND ?o[eg:att_1 -> ?x eg:att_1 -> ?y] >> AND NOT(?x=?y) >> Then Do(Assert(rif:cardinality-violation(?o, att_1, ?x, ?y)) Halt) >> Forall ?o, ?x If ?o#eg:MyClass AND ?o[eg:att_1 -> ?x ] AND >> NOT(pred:isString(?x)) >> Then Do(Assert(rif:datatype-violation(?o, att_1, ?x, xs:string)) Halt) >> Forall ?o, ?x If ?o#eg:MyClass AND ?o[eg:att_2 -> ?x ] AND >> NOT(pred:isDate(?x)) >> Then Do(Assert(rif:datatype-violation(?o, att_2, ?x, xs:date)) Halt) >> >> (Core) >> // just a comment >> >> Note that although the meaning of the class statement in PRD is given as >> a set of rules on multi-valued frames, it would typically be implemented >> procedurally using single valued statically typed objects. >> >> Gary Hallmark wrote: >> > Yes, this is one of the top issues to resolve. >> > I think it is especially important to be able to translate Core >> > rulesets with frames to production rules with Java objects in a way >> > that is "natural" -- i.e. the Java objects don't need a bunch of >> > List-valued fields "just in case" the Core rules might conclude >> > multiple slot values. >> > >> > More comments inline... >> > >> > Christian de Sainte Marie wrote: >> >> >> >> All, >> >> >> >> In view of the coming F2F, let us restart this thread. >> >> >> >> Here is a summary of the requirements, the problem and the proposed >> >> solutions that have been discussed at one point or another. >> >> >> >> 1. Requirements >> >> >> >> The PRD crowd requires a way to represent objects, that is, >> >> essentially to distingish single-valued attributes from multi-valued >> >> ones. >> >> >> >> Using frames to represent object-attribute-value triples, that means >> >> that PRD wants a way >> >> to distinguish an attribute "att_1" to which the following axiom >> >> applies: >> >> >> >> (1) Forall ?o, ?x, ?y, If ?o[att_1 -> ?x] AND ?o(att_1 -> ?y] Then ?x >> >> = ?y >> >> >> >> >> >> from an attribute "att_2" that does not satisfy it. >> >> >> >> One consequence of attribute single-valuedness, apparently the only >> >> one, is that, in the >> >> case of a single-valued attribute, the semantics of an action that >> >> asserts a new value of >> >> the attribute, in PR languages, is the replacement of the attribute's >> >> value by the asserted >> >> value (whereas it is addition of the newly asserted value, in the >> >> case of multi-valued >> >> attributes). >> >> >> >> 2. Problem >> >> >> >> One problem is that the axiom (1), above, cannot be expressed in PRD >> >> (nor in Core). >> >> >> > The axiom is not a very good one. It's the best we can do in BLD. It >> > just says that a cardinality violation makes your ruleset >> > inconsistent. In PRD, you could say >> > >> > Forall ?o, ?x, ?y, If ?o[att_1 -> ?x att_1 -> ?y] AND NOT(?x=?y) Then >> > Do(Assert(rif:cardinality-violation(?o, att_1, ?x, ?y)) Halt) >> > >> > In Core, there's not much you can say. >> > >> > >> >> >> >> 3. Proposed solutions >> >> >> >> (a) Annotate, in the RIF document, the attribute as single-valued, >> >> e.g. using RIF meta-data >> >> construct; >> >> >> >> (b) Modify the Frame construct, so that the multiplicity of an >> >> attribute is indicated >> >> explicitly, e.g. adding a "cardinality" attribute to the <slot> element; >> >> >> >> (c) Specify a new construct, specific to the case of single valued >> >> attributes (that is, >> >> with multiplicity = 1), keeping the Frame construct unchanged (that >> >> is the multiplicity of >> >> attributes is 0..*). E.g. csma's proposal to introduce a new basic >> >> term to represent the >> >> value of a single valued attribute (in [1]; but [1] contains other >> >> proposals as well, which >> >> has muddled the discussion); >> >> >> >> (d) Leave attribute multiplicity implicit in condition formulas and >> >> rely on RIF document >> >> analysis to determine attributes multiplicity: the only attributes >> >> that need be modelled as >> >> single valued are those of Frames that appear in assertions with >> >> replacement semantics, in >> >> the conclusion of at least one rule; >> >> >> >> (e) Rely on out-of-band information (e.g. interchange of the intended >> >> data model, in >> >> parallel to the RIF document) to determine the multiplicity of >> >> Frames' attributes; >> >> >> >> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0009.html >> >> >> >> </chair> >> >> My preference goes to (c) (whether my proposed implementation of it >> >> or an alternative is a >> >> different question), for the following reasons: >> >> >> >> - (a) uses metadata for something that impacts the semantics of the >> >> rules; >> >> >> >> - although the data model, that is assumed in the representation of >> >> the rules for the data >> >> to which the rules apply, is something that is completely orthogonal >> >> to the rules, (a) and >> >> (b) rely on RIF to interchange explicitely a part of that data model >> >> (i.e. the multiplicity >> >> of attributes); >> >> >> >> - (a), (b), (d) and (e) all use the Frame construct to represent >> >> single-valued >> >> attributes as well as multi-valued ones, although the >> >> object-attribute-value triple is >> >> redundant in the single-valued case (indeed, for single-valued >> >> attributes, the object- >> >> attribute pair determines the value unequivocally), and requires, in >> >> many cases, the >> >> introduction of dummy variables in the RIF representation of the rules. >> >> >> >> - (d) works only for PRD; >> >> >> >> - (e) works only if the required out-of-band information is >> >> available, and if a way to >> >> relate it to the RIF representation of the rules has been specified, >> >> which is a lots of >> >> ifs... >> >> >> > I have a proposal (f). >> > I propose that we have some common syntax to denote cardinality >> > constraints on frame slots in Core (and thus also in BLD and PRD). BLD >> > and PRD will give this syntax a semantics (using the above rules) but >> > Core will formally treat the cardinality constraints as comments. >> > >> > A PRD translator could translate a single-valued frame slot to a >> > nillable single-valued object field (where nil is a value not in the >> > Domain). The translator could generate code to test for an attempt to >> > assign a value to a non-nil field and produce a >> > rif:cardinality-violation. >> > >> > So what is this common syntax? I propose that we declare the >> > cardinality constraints once in the ruleset rather than repeat them >> > each time a slot is accessed in a frame formula. Something like >> > >> > class eg:MyClass [ eg:att_1->singleton, eg:att_2->set ] >> > >> > would say that att_1 is single-valued but att_2 is multi-valued. Or, >> > >> > class eg:MyClass [ eg:att_1->xs:string, eg:att_2->set(xs:date) ] >> > >> > would also give datatype constraints to frame slots, also nice to have >> > for better object support. >> >> >> > >> > >> > >> >> > > -- Cheers, Gary HallmarkReceived on Tuesday, 31 March 2009 20:10:42 UTC

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