W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2009

Re: [ISSUE-94] Object representation

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Thu, 2 Apr 2009 14:26:00 -0700
Message-ID: <499257640904021426q4223f99bi9d12a88023acb076@mail.gmail.com>
To: Dave Reynolds <der@hplb.hpl.hp.com>
Cc: public-rif-wg@w3.org
Dave,

If I have this ruleset:

_o#eg:MyClass
_o[eg:att_1->_o]
 rif:error('type violation for eg:att_1, expected a string') :-
     ?o#eg:MyClass AND ?o[eg:att_1 -> ?x] AND
          pred:isLiteralNotOfType(?x, xsd:string)

Isn't it the case that no rif:error is entailed even though att_1 is
bound to something that is not a string?



On Thu, Apr 2, 2009 at 1:17 AM, Dave Reynolds <der@hplb.hpl.hp.com> wrote:
> You can express some notion of constraint in Core. What we do with the OWL 2
> RL rules is define a predicate (rif:error) which signals to the calling
> application that there was an inconsistency and so that any other
> entailments should be disregarded.
>
> rif:error('type violation for eg:att_1, expected a string') :-
>      ?o#eg:MyClass AND ?o[eg:att_1 -> ?x] AND
>           pred:isLiteralNotOfType(?x, xsd:string)
>
> Of course this is not a constraint rule, it doesn't lead to any reasoning
> about constraints nor prevent other inferences being drawn.
>
> But for OWL 2 RL, and I suspect for your case, it does the job, i.e. the
> calling application has a means to check for consistency (of the OWL 2 RL
> ontology in our case) by testing whether the rule set derives rif:error.
>
> I guess the underlying question is what you are trying to achieve by this
> axiomatization of Java constraints in RIF.  You might be tying to:
> (a) communicate the constraints so consuming translators can optimize their
> frame representation,
> (b) provide a means to do consistency checking so that rulesets which
> violate the constraints can be detected at run time,
> (c) use the constraints as part of the inference process to, for example,
> trigger some reasoning-by-cases to find branches which don't violate the
> constraints.
>
> For (a) you want a separate schema language (possibly attached via metadata
> annotations), for (b) the error predicate trick is sufficient, for (c) you
> probably[1] need a different dialect.
>
> Sorry if I'm off base here, I haven't been following the object
> representation discussions very closely.
>
> Dave
>
> [1] You can get some way with expressing real constraints in BLD (not Core)
> by using Jos' trick of entailing an inconsistent term like "1=2".
>
> Gary Hallmark wrote:
>>
>> Thanks, Michael.
>> This thread started talking about "better" object support in RIF, and I
>> interpret that as a need for constraints on frame slot cardinality and
>> datatype. The good news is that BLD and PRD seem expressive enough for
>> cardinality constraints. The difficulty is how to put cardinality
>> constraints in Core so that practical interoperation between BLD and PRD is
>> possible, even though you can't actually express the cardinality constraints
>> as Core rules.
>>
>> It's interesting that BLD is not expressive enough for datatype
>> constraints. I think both cardinality and datatype constraints are needed to
>> translate between RIF and a target rule language that uses an O-O datamodel
>> like Java. To translate to RIF, you need some way to axiomatize a Java
>> object as a frame, and I see no way to do that without cardinality and
>> datatype constraints. To translate from RIF, you need some way to recognize
>> a frame plus its axioms so you know what kind of Java object can be used
>> (what are the cardinalities and datatypes of its fields).
>>
>> On Wed, Apr 1, 2009 at 9:47 PM, Michael Kifer <kifer@cs.sunysb.edu
>> <mailto:kifer@cs.sunysb.edu>> wrote:
>>
>>
>>    On Wed, 1 Apr 2009 21:14:36 -0700
>>    Gary Hallmark <gary.hallmark@oracle.com
>>    <mailto: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.
>>     > > > >> >>
>>     > > > >> >
>>     > > > >> >
>>     > > > >> >
>>     > > > >>
>>     > > > >>
>>     > > > >
>>     > > > >
>>     > > >
>>     > > >
>>     > > >
>>     > >
>>     >
>>     >
>>     >
>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Gary Hallmark
>>
>
>



-- 
Cheers,

Gary Hallmark
Received on Thursday, 2 April 2009 21:26:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:04 GMT