- From: Paul Vincent <pvincent@tibco.com>
- Date: Fri, 7 Dec 2007 01:53:38 -0800
- To: "Dave Reynolds" <der@hplb.hpl.hp.com>
- Cc: "Public-Rif-Wg \(E-mail\)" <public-rif-wg@w3.org>
> You took my quote out of context. Oops. Apologies. " In the case of the Semantic Web stack, of which RIF is a part ..." I read as an unconditional declaration of RIF being a part of the semantic web, which could be misinterpreted, and is therefore a statement to avoid IMHO. > My point was there are different > stacks RIF might want to work with each of which already has their own > way of handling these things. Fully agree. > Sounds like you have a use case to share! Christian has previously said > this would be very unusual in PR applications. It may certainly be unusual for *interchangeable* PR applications, but a subclass mechanism may be used as a convenient way to store a local result in objects that are not needed outside the rule system. Example: for electronic contract exchange, I may used a corporate contract XML schema, but find that I want to store intermediate rule processing results inside the rule engine for other rules to use. So I may subclass Econtract to EcontractForServices and add an attribute AppropriateSkillLevelApplied, computed from some other data. I use this in the rules but the external class / XML schema is not under my control. For interchange I would probably solve this some other way eg with a local XML schema of extensions, or I would force a fix to the external schema, etc. Most PR engines are implemented in a 3GL / import XML (etc) into a Java representation, which allows them some flexibility over object model definitions. So subclassing an XML-derived class is not a big issue. But it is NOT of interest to try and standardize these mechanisms (I suggest) in RIF. Hence I fully concur with Christian (PRD should not bother with such a mechanism). However, I can fully understand why an AI-type / knowledgebase application would want to include / embed schema info into its knowledgebase. Its just that this is not "core" to "RIF" IMHO. Paul Vincent TIBCO | ETG/Business Rules > -----Original Message----- > From: Dave Reynolds [mailto:der@hplb.hpl.hp.com] > Sent: 07 December 2007 09:22 > To: Paul Vincent > Cc: Public-Rif-Wg (E-mail) > Subject: Re: Reminder: pending discussion "membership" (pending discussion > on ACTION-350) > > Paul Vincent wrote: > >> Using your data modelling language of choice. In the case of the > >> Semantic Web stack, of which RIF is a part, the answer is RDFS/OWL. > > > > Semantics schemantics. RIF includes non sem web requirements/features > > etc, so it at best is a "shared part" of the Sem Web stack. IMHO. :) > > You took my quote out of context. My point was there are different > stacks RIF might want to work with each of which already has their own > way of handling these things. > > At previous F2F we've agreed that the two important stacks it needs to > work with are semweb and XML. > > The sentence you quoted was saying "*if* you are working in semweb then > ...". Likewise the next one was saying "*if* you are working in XML > Schema then ...". > > >> I am convinced that including these primitives moves RIF from the > > domain > >> of rule interchange into that of data model interchange. Had that been > >> explicitly part of the RIF charter I am not certain we would have > >> approved the formation of RIF. > > > > Funny I originally drafted a similar point in my other response, on the > > premise that Michael used the term "knowledgebase" instead of rulebase, > > and that a Knowledge Interchange Format should be considered an > > extension to RIF, if a KIF is desired. > > > > But, pragmatically, quite often rulebases (eg in PR) include things like > > local variable definitions, and sometimes even local subclass > > definitions, to simplify rule language expressions when the domain > > schema is "fixed" and needs "extending" in the rule system. So I have > > some sympathy for Michael's position. > > Sounds like you have a use case to share! Christian has previously said > this would be very unusual in PR applications. > > > 1. For the RIF use cases, we would typically want (for PR) an XML doc + > > schema to form the factbase. > > Exactly. So how are subclass relations supposed to be connected to XML > Schema? > > Dave > -- > Hewlett-Packard Limited > Registered Office: Cain Road, Bracknell, Berks RG12 1HN > Registered No: 690597 England > > > > 2. The RIF charter implies (per my reading) that anything outside of the > > definition of rule should be considered a non-core extension. > > > > 3. The AI / Sem Web community are divided on the value of class > > membership constructs in BLD. > > > > My simple inference from this discussion that perhaps BLD should be > > BLCore (no "schema features") and BLDialect (BLCore + "schema > > features")? > > > > Paul Vincent > > TIBCO | ETG/Business Rules > > > > > >> -----Original Message----- > >> From: public-rif-wg-request@w3.org > > [mailto:public-rif-wg-request@w3.org] > >> On Behalf Of Dave Reynolds > >> Sent: 07 December 2007 08:52 > >> To: Michael Kifer > >> Cc: axel@polleres.net; Public-Rif-Wg (E-mail) > >> Subject: Re: Reminder: pending discussion "membership" (pending > > discussion > >> on ACTION-350) > >> > >> > >> Michael Kifer wrote: > >>> CSMA had an action to bug me about the ## feature :-) > >>> I thought that others might also be interested, so I am including my > >>> arguments below. > >>> > >>> First, one needs to be able to specify that one class is a subclass > > of > >>> another class **as part of the KB**. > >> I disagree, at least if by KB you mean RIF rules rather than RIF rules > > + > >> externally specified ontology or data model. > >> > >> Expressing data models or ontological models and any subClass > > relations > >> associated with them is not a RIF requirement. > >> > >>> For instance, > >>> > >>> student##person. > >>> father(person)##person. > >>> > >>> In KB apps this is used for reasoning, not just as part of a data > >>> model. How would one specify this info otherwise? > >> Using your data modelling language of choice. In the case of the > >> Semantic Web stack, of which RIF is a part, the answer is RDFS/OWL. > >> > >> In the case of XML Schema models then complex types can be related by > >> both extension and restriction in ways that don't neatly map to > > subClass. > >>> Here is a more sophisticated example: parametrised lists. > >>> > >>> list(?Subclass) ## list(?Super) :- ?Subclass ## ?Super. > >>> > >>> (List of FOOs is a subclass of lists of BARs if FOO is a subclass of > >>> BAR. We could have list(father(person)), for example.) > >>> > >>> RDF's subclassOf does not cut it because > >>> > >>> 1. It imposes additional axioms, which are not commonly accepted. > >>> 2. It is also not even defined for classes specified using function > >> terms > >>> (like list(?Foo)). > >>> > >>> Both arguments are also applicable to the RDF membership > > relationship. > >>> I am convinced that throwing out these primitives serves no purpose > > and > >>> will just gratuitously cripple the BLD. > >> I am convinced that including these primitives moves RIF from the > > domain > >> of rule interchange into that of data model interchange. Had that been > >> explicitly part of the RIF charter I am not certain we would have > >> approved the formation of RIF. > >> > >> Dave > >> -- > >> Hewlett-Packard Limited > >> Registered Office: Cain Road, Bracknell, Berks RG12 1HN > >> Registered No: 690597 England > >
Received on Friday, 7 December 2007 09:53:59 UTC