Re: Issues with classification a#b, a##b

one scenario is an ilog user develops a data model and a ruleset and 
wants to sent that to an oracle user using RIF.  If all that comes 
through is the ruleset but not the data model, the oracle user won't be 
able to make as much sense of the ruleset as they might be able to if 
the data model also came along.

Paul Vincent wrote:

> Gary - there are 2 scenarios:
>
> 1 the original (business object model) schema is reverted to for 
> editing and execution
>
> 2 there is no original object model so the (business) user is stuffed 
> anyway
>
> AFAIK scenario 1 is the main one for PR users
> So what am I missing?
>  
> Regards,
> Paul Vincent, TIBCO, from my handheld
>
> ----- Original Message -----
> From: Gary Hallmark <gary.hallmark@oracle.com>
> To: Paul Vincent
> Cc: Dave Reynolds <der@hplb.hpl.hp.com>; RIF <public-rif-wg@w3.org>
> Sent: Thu Jul 26 14:39:54 2007
> Subject: Re: Issues with classification a#b, a##b
>
> To try and summarize, I am concerned about translating from RIF to
> Oracle Business Rules for the purpose of viewing and editing those
> rules.  The issue is that our UI tooling will immerse the user in an
> enviroment described by the data model.  If the data model describes
> purchase orders, customers, etc. then the business user will be
> comfortable.  If the data model is triples or name value pairs or
> untyped frames or uniterms then we will need an extra manual step in the
> translation process to divine a business-friendly data model, and we may
> be subject to errors if mistakes are made in this manual step.
>
> Paul Vincent wrote:
>
> >I'm a little confused by the below discussion: surely if I am
> >interchanging PR based on say an XML/XSD data model, I would not be
> >editing rules in RIF format anywhere? The real issue is: does it make
> >sense to map from a static-typed-data-model to a dynamic-typed-model and
> >back again during a RIF interchange transaction between 2 PR systems as
> >part of an XML document+rules interchange? For sure one "problem" would
> >be that I will have some XML data structure alongside some rules which
> >may not be readily "readable" against the data (eg for a contract
> >exchange use case). This affects usability IMHO.
> >
> > 
> >
> >>Gary Hallmark wrote:
> >>
> >>   
> >>
> >>>Dave Reynolds wrote:
> >>>
> >>>     
> >>>
> >>>>>>Take a concrete example:
> >>>>>>
> >>>>>>    :Dave rdf:type :Person .
> >>>>>>    :Dave foaf:name  "Dave" .
> >>>>>>    :Person rdfs:subClassOf :Animal .
> >>>>>>
> >>>>>>In Jos's translation this would correspond to RIF Frames:
> >>>>>>
> >>>>>>    :Dave [rdf:type -> :Person, foaf:name -> "Dave"] /\
> >>>>>>                          :Person[rdfs:subClassOf :Animal]
> >>>>>>
> >>>>>>   ?p # ?t :- ?p[rdf:type -> ?t] .
> >>>>>>   ?p ## ?t :- ?p[rdfs:subClassOf -> ?t] .
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>In this case the mappings to # and ## seems to buy us little.
> >>>>       
> >>>>
> >>>In a way I agree, but only because I would like static declarations
> >>>     
> >>>
> >such
> > 
> >
> >>as
> >>   
> >>
> >>>FrameType Person##Animal [ name -> xsd:string ]
> >>>
> >>>I'm not sure I can use the rules above because I need to extract the
> >>>'business data model" from the RIF document before I can translate
> >>>     
> >>>
> >the
> > 
> >
> >>>rules.  All this occurs at translation time, which is before the
> >>>     
> >>>
> >rules
> > 
> >
> >>>are executed.
> >>>     
> >>>
> >>Yes. There is a fairly fundamental difference between strong
> >>   
> >>
> >statically
> > 
> >
> >>typed systems and weak or dynamically typed. If you need a RIF dialect
> >>with static typing and want to use #/## for that then you will need a
> >>different interpretation of # and ## than anyone who might, for
> >>   
> >>
> >example,
> > 
> >
> >>want to infer isa or sub relationships for whatever reason.
> >>
> >>I guess this is a core question for the RIF PRD sub-group, are all
> >>relevant PR systems statically typed and is static typing in RIF be
> >>necessary for efficient translation?
> >>
> >>   
> >>
> >>>>We risk ending up with a nest of incompatible mappings. Gary, for
> >>>>example, would likely implement #/## by mapping to Java classes
> >>>>       
> >>>>
> >>>yes
> >>>
> >>>     
> >>>
> >>>>and would then be unable to translate rules like the above
> >>>>       
> >>>>
> >>>the problem seems to be that without static declarations I need to
> >>>     
> >>>
> >run
> > 
> >
> >>>the rules in order to translate the data model that I need in order
> >>>     
> >>>
> >to
> > 
> >
> >>>translate the rules...
> >>>
> >>>     
> >>>
> >>>>and would be unable to work with RDF data. Not a problem for him
> >>>>       
> >>>>
> >right
> > 
> >
> >>>>now but given Oracle's investment in RDF and OWL it might be a
> >>>>       
> >>>>
> >problem
> > 
> >
> >>>>in the future. Yet there is no difficulty in using Oracle's rule
> >>>>engine to process RDF data if it weren't for this seemingly
> >>>>       
> >>>>
> >artificial
> > 
> >
> >>>>requirement to map different class hierarchy concepts to the same
> >>>>       
> >>>>
> >#/##
> > 
> >
> >>>>machinery.
> >>>>       
> >>>>
> >>>I have to disagree.  RDF poses great difficulty because of the
> >>>difficulty in extracting a static declaration like the one above.
> >>>     
> >>>
> >>OK, this is somewhat off the main topic, my fault for making the
> >>comment. Let me respond briefly but perhaps we should chat about it
> >>   
> >>
> >over
> > 
> >
> >>a beer at the next f2f rather than weigh down the list too much.
> >>
> >>   
> >>
> >>>Our
> >>>UI tools require a data model so that rules can be phrased in
> >>>     
> >>>
> >structured
> > 
> >
> >>>English like
> >>>
> >>>IF *Person.name* = "Dave"
> >>>THEN ...
> >>>
> >>>Items marked with *stars* are pick lists in the UI that are driven
> >>>     
> >>>
> >off
> > 
> >
> >>>the data model.
> >>>Without a static data model, I'd have to have something generic like
> >>>
> >>>IF  *Frame.property1* =  "rdf:type" and *Frame.value1* = ":Person"
> >>>     
> >>>
> >and
> > 
> >
> >>>*Frame.property2* = "foaf:name" and *Frame.value2* = "Dave"
> >>>THEN
> >>>
> >>>This latter mess is unsuitable for a business user (or for me, for
> >>>     
> >>>
> >that
> > 
> >
> >>>matter).
> >>>     
> >>>
> >>Sure, though this is confusing the UI and rule authorship issues with
> >>the rule engine issues.
> >>
> >> From the engine point of view the RDF data model is static (there are
> >>just triples and nodes, triples have three fields etc). So if there
> >>   
> >>
> >were
> > 
> >
> >>a reason to do so you could have a generic RDF data model in Java and
> >>write rules over that. That's basically what you would need to do
> >>   
> >>
> >anyway
> > 
> >
> >>to implement the untyped Frames (not Classifications) in the current
> >>   
> >>
> >RIF
> > 
> >
> >>draft.
> >>
> >>Whilst your group might have no interest in that right now, it is not
> >>completely irrelevant to Oracle. Oracle are certainly selling RDF/OWL
> >>support at the moment and are actively promoting use of RDF rules for
> >>data integration in an enterprise setting [1]. It just seems at least
> >>plausible that since you have two rule engines then one day someone
> >>(perhaps a customer) might want them to interoperate via RIF :-), and
> >>one of those rules engines is currently used to process RDF data.
> >>
> >>   
> >>
> >>>IMHO, the lack of an explicit static data model for RDF makes it
> >>>     
> >>>
> >hard to
> > 
> >
> >>>build UI tools, and without good UI tools you aren't going to get
> >>>     
> >>>
> >far in
> > 
> >
> >>>the business software marketplace.
> >>>     
> >>>
> >>Humm.
> >>
> >>On the one hand I agree with you that open extensible data models do
> >>raise UI challenges and there are innovations to be made in that area.
> >>
> >>However, in practice people do often work within the confines of
> >>particular vocabularies, expressed via RDFS or OWL ontologies. So you
> >>can have UI tooling that allow you to pick from terms in your current
> >>active vocabularies. The difference is that in a semantic web setting
> >>users expect to be able to load in new ontologies or extend existing
> >>ones. Good UIs for that are not trivial but nor are they impossible.
> >>
> >>Certainly several commercial OWL editors have quite usable UIs and
> >>permit manipulation of RDF instance data.
> >>
> >>Dave
> >>
> >>[1]
> >>
> >>   
> >>
> >http://www.oracle.com/technology/tech/semantic_technologies/pdf/semantic
> >11
> > 
> >
> >>g_dataint_twp.pdf
> >>
> >>--
> >>Hewlett-Packard Limited
> >>Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> >>Registered No: 690597 England
> >>   
> >>
> >
> > 
> >
>
> --
>
>
> Oracle <http://www.oracle.com>
> Gary Hallmark | Architect | +1.503.525.8043
> Oracle Server Technologies
> 1211 SW 5th Avenue, Suite 800
> Portland, OR 97204
>

-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204

Received on Friday, 27 July 2007 00:21:39 UTC