- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 03 Apr 2009 08:59:06 +0100
- To: Gary Hallmark <gary.hallmark@oracle.com>
- CC: public-rif-wg@w3.org
Gary Hallmark wrote:
> 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?
It won't be entailed, that's true, but since we have no way of saying
that eg:MyClass is disjoint from xsd:string then you can't claim that _o
is not a string. That's the problem with these open domain symbol spaces
(rif:iri, rif:local).
I.e. I don't think the following is inconsistent by BLD semantics:
_o#eg:MyClass
_o[eg:att_1->_o]
_o = "foo"
nor is:
"foo"#eg:MyClass
"foo"[eg:att_1->"foo"]
So your NOT operator would have the same problem it's not (just) a
limitation of isLiteralNotOfType its a feature of the BLD semantics.
Dave
> 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
>>>
>>
>
>
>
Received on Friday, 3 April 2009 07:59:57 UTC