Re: [ISSUE-94] Object representation

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.

> 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. 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.
What if I have a fact like

...[att_1-> 1, att_2->2].

Then the above rule is inconsistent.
Also, builtin predicates are not allowed in rule heads.

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.
> >>
> >
> >
> >
> 
>

Received on Tuesday, 31 March 2009 17:43:17 UTC