Re: [ISSUE-94] Object representation

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)

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.

> 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

Received on Tuesday, 31 March 2009 20:10:42 UTC