Re: [ISSUE-94] Object representation

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 Friday, 27 March 2009 20:30:58 UTC