Re: [ISSUE-94] Object representation

I am all for inclusion of constraints and cardinality in BLD.
Not sure if we have the same idea about cardinality, but I would do it also
through constraints.
One other way to express it is through annotations. In BLD,
such an annotation would not affect the semantics - they are just a pragma.
In PRD, however, they might be affecting the semantics.

michael

On Thu, 2 Apr 2009 00:35:25 -0700
Gary Hallmark <gary.hallmark@oracle.com> wrote:

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

Received on Thursday, 2 April 2009 15:12:20 UTC