Re: [ISSUE-94] Object representation

On Tue, 31 Mar 2009 13:10:07 -0700
Gary Hallmark <gary.hallmark@oracle.com> wrote:

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

Ah, ok. Missed the ?y thingie.


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

But builtin predicates cannot appear in the rule heads.
What you need are constraints like

!- ?o#eg:MyClass AND ?o[eg:att_1 -> ?x] AND Not pred:isString(?x).

But we don't have constraints and (more importantly) Not.
(Constraints can be had if we introduce the predicates True and False, so it is
a minor problem.)

michael


 

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

Received on Tuesday, 31 March 2009 21:03:02 UTC