Re: [ISSUE-94] Object representation

example of my proposal:

the statement "class eg:MyClass [ eg:att_1->xs:string, 
eg:att_2->set(xs: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)

(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 Tuesday, 31 March 2009 06:22:35 UTC