W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2008

Reference vs import <-- RIF Core shortened

From: Paul Vincent <pvincent@tibco.com>
Date: Wed, 19 Nov 2008 13:27:50 -0800
Message-ID: <A92210407BA7004199621BE5F0AC5D8B1B6FDC@NA-PA-VBE04.na.tibco.com>
To: "Gary Hallmark" <gary.hallmark@oracle.com>, "Christian de Sainte Marie" <csma@ilog.fr>
Cc: <kifer@cs.sunysb.edu>, "Patrick Albert" <palbert@ilog.fr>, "Dave Reynolds" <der@hplb.hpl.hp.com>, "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>, "Adrian Paschke" <Adrian.Paschke@gmx.de>, "Axel Polleres" <axel.polleres@deri.org>, "RIF WG" <public-rif-wg@w3.org>

Sorry to say I've not been following (/understanding) this discussion
too closely (as AFAIK core is defined as the intersection of BLD and PRD
and the latter is not defined yet). 

Christian's comment is simply (?) that RIF needs to play well alongside
externally-defined fact definitions (for example external Java object
models used to define production rules in BREs). 

Maybe the qu is whether it is compulsory that all relevant facts and
class relationships need to be represented in RIF for RIF rules to be
defined against them?

If so - then this is a bit of an additional (& unnecessary for the
purposes of mere interchange) burden for BRE vendors wanting to support
RIF PRD for common use cases of writing RIF rules against XML documents.

If not - can "core" still make sense if some parts of the fact model
definitions are not embedded but are external references?

Or have I missed the point (again)? :)

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP

> -----Original Message-----
> From: public-rif-wg-request@w3.org
> On Behalf Of Gary Hallmark
> Sent: 18 November 2008 21:07
> To: Christian de Sainte Marie
> Cc: kifer@cs.sunysb.edu; Patrick Albert; Dave Reynolds; Boley, Harold;
> Adrian Paschke; Axel Polleres; RIF WG
> Subject: Re: RIF Core shortened
> The effect of importing an XML document, an RDF graph, an OWL
> or another RIF document is to internalize some axioms, in effect to
> translate them to RIF.  Therefore, one must be able to express those
> axioms in RIF.  Those axioms include naturally the ATOMIC syntactic
> class, excluding equality.  I don't see how it is possible to
> an imported element to, say, membership but have no way to assert
> membership.
> Maybe the confusion is about importing vs. External predicates,
> etc.  Import actually internally defines what it imports.  External
> predicates always return the same answer - they are stateless.
> Christian de Sainte Marie wrote:
> >
> > Gary Hallmark wrote:
> >
> >> I do not know what an "externally defined data model" is.
> >
> > E.g. an XML Schema (I had your strawman on that subject [1] in
> >
> > [1]
> >
> >> I like the SWC model, where one can import an RDF graph or OWL
> >> ontology.  But the semantics is defined by mapping those imported
> >> things to the RIF data model, i.e. herbrand terms and frames.  I
> >> think a similar approach works for schema-valid XML.  But that may
> >> mean, depending on how one interprets what an external data model
> >> that it is precisely the facts of the form o#C where C is imported
> >> from an XML document (is this an external data model?) that is
> >
> > Yes. I understand that. But the way the semantics is specified in
> > does not require that the XML schema be translated in PRD, not
> > than it is required that the WM be translated in PRD etc. Of course,
> > it requires that the mapping be specified; but not that the facts be
> > actually asserted in PRD (they are pre-existing in the externally
> > defined data model, if you like).
> >
> > My point is that being able to assert membership facts is not
> > for that reason.
> >
> > Now, that does not mean that there are no, other, legitimate reasons
> > to allow the assertion of such fact.
> >
> > I detailled my analysis of what should be allowed and what not, but
> > this is just my contribution to the discussion...
> >
> > Cheers,
> >
> > Christian
> >
> >
Received on Wednesday, 19 November 2008 21:29:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:53 UTC