- From: Gary Hallmark <gary.hallmark@oracle.com>
- Date: Thu, 2 Apr 2009 14:26:00 -0700
- 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 UTC