RE: Reference vs import <-- RIF Core shortened

Thanks Gary,

> From: Gary Hallmark [mailto:gary.hallmark@oracle.com]
> I would say that it *is* compulsory that all relevant facts and class
> relationships be *representable* in RIF.  

[PV>] This seems reasonable if you believe there is required for the
semantic validation of the RIF PRD design. 

> But as a practical matter, if
> my RIF translator receives a RIF document with an "import foo.xml"
> directive in it, then it probably won't actually convert foo.xml to
RIF,
> although it certainly could.  

[PV>] I agree this is not needed at runtime in such constrained cases as
rules-alongside-an-agreed-XSD-based-DSL.

> What my translator must do is translate
> the data in foo.xml to my target system in a manner that conforms to
the
> RIF semantics.  

[PV>] For the use case I am thinking of, your source and target systems
will already have agreed on the XSD eg MISMO version X. So the likely
runtime process is source exports XML doc A and RIF doc A, and target
imports XML doc A and RIF doc A. Normally I would not expect RIF to do
*any* data translating. Although it will likely refer to the xsd. 

[Consider if I am running the same rules over 1000s of XML documents. I
certainly won't want RIF to be concerned with translating these
"factbases".]

Possibly this is what you meant here anyway :)

> The way we specify the semantics of the facts in foo.xml
> is via a simple syntactical transformation into RIF, and then we let
the
> RIF semantics take over.  So clearly, these xml facts must be
> representable in RIF.  I don't know how to specify the semantics of
> RIF+somethingElse where that somethingElse isn't a subset of RIF.
> 
> BTW, many "facts" in foo.xml aren't easily representable in RIF Core
> (e.g. datatype constraints and cardinality constraints).  So the xml
> import will be lossy.

[PV>] That's an interesting point. Most BREs are "lossy" in their
Business Object Model representations in this way - few today for
example represent general data constraints, or how to use them in rule
actions, except maybe as "exception rules". Nonetheless, you could
consider RIF translators that imported such XSD or XPath-based
constraints as rules for execution. I'd suggest that would be a new
dialect, called something like CB-PRD constraint-based PRD (etc).

> 
> Paul Vincent wrote:
> > 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
> >>
> > [mailto: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
> >>
> > ontology,
> >
> >> 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
> >>
> > translate
> >
> >> an imported element to, say, membership but have no way to assert
> >> membership.
> >>
> >> Maybe the confusion is about importing vs. External predicates,
> >>
> > frames,
> >
> >> 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
> >>>
> > mind).
> >
> >>> [1]
> >>>
> > http://lists.w3.org/Archives/Public/public-rif-wg/2008Oct/0046.html
> >
> >>>> 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
> >>>>
> > is,
> >
> >>>> 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
> >>>>
> > needed.
> >
> >>> Yes. I understand that. But the way the semantics is specified in
> >>>
> > PRD
> >
> >>> does not require that the XML schema be translated in PRD, not
> >>>
> > anymore
> >
> >>> 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
> >>>
> > required
> >
> >>> 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 Thursday, 20 November 2008 08:30:15 UTC