Re: [ISSUE-94] Object representation

Thanks, Michael.
This thread started talking about "better" object support in RIF, and I
interpret that as a need for constraints on frame slot cardinality and
datatype. The good news is that BLD and PRD seem expressive enough for
cardinality constraints. The difficulty is how to put cardinality
constraints in Core so that practical interoperation between BLD and PRD is
possible, even though you can't actually express the cardinality constraints
as Core rules.

It's interesting that BLD is not expressive enough for datatype constraints.
I think both cardinality and datatype constraints are needed to translate
between RIF and a target rule language that uses an O-O datamodel like Java.
To translate to RIF, you need some way to axiomatize a Java object as a
frame, and I see no way to do that without cardinality and datatype
constraints. To translate from RIF, you need some way to recognize a frame
plus its axioms so you know what kind of Java object can be used (what are
the cardinalities and datatypes of its fields).

On Wed, Apr 1, 2009 at 9:47 PM, Michael Kifer <kifer@cs.sunysb.edu> wrote:

>
> On Wed, 1 Apr 2009 21:14:36 -0700
> Gary Hallmark <gary.hallmark@oracle.com> wrote:
>
> > Michael wrote:
> >
> > > But builtin predicates cannot appear in the rule heads.
> >
> >
> > Maybe they should be allowed.  Does pred:isString("foo") causes any more
> > problems in the head  than 1=1 ?  Or does pred:isString(1) cause more
> > difficulties than does 0=1 ?
>
> No, built-in preds cannot be allowed in BLD in the head in principle. It
> will
> not be Horn any more. For instance, you might infer
> integer(http://abc/cde^^rif:iri) and then this implies Exists ?X
> integer(?X)
> and ?X=http://abc/cde.
>
>
> > > What you need are constraints like
> > >
> > > !- ?o#eg:MyClass AND ?o[eg:att_1 -> ?x] AND Not pred:isString(?x).
> >
> >
> > Yes, that's what I proposed for PRD (PRD has NOT).
>
> So, this is what you want then.
>
>
> > > But we don't have constraints and (more importantly) Not.
> >
> > Right.  And I'm not proposing NOT for BLD. I am proposing datatype guards
> in
> > the head, to function as a "poor man's" datatype integrity constraint, in
> > the same way that we use equality in the head to function as a poor man's
> > cardinality constraint.
>
> No, these guards are anathema to BLD :-)
>
>
> > > (Constraints can be had if we introduce the predicates True and False,
> so
> > > it is
> > > a minor problem.)
> >
> > What does your notion of Constraint do when it is violated?  Make the
> > ruleset inconsistent? or something else?
>
> Yes, inconsistent. Like in the Oracle DB :-)
>
> m
>
>
> >
> > >
> > >
> > > 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.
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>



-- 
Cheers,

Gary Hallmark