- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Thu, 02 Apr 2009 09:17:11 +0100
- To: Gary Hallmark <gary.hallmark@oracle.com>
- CC: public-rif-wg@w3.org
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
>
Received on Thursday, 2 April 2009 08:18:08 UTC