Re: [ISSUE-94] Object representation

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 04:48:19 UTC