Re: [ISSUE-94] Object representation

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 ?

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

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

>
> (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?

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