[rules-dev] Knowledge Composition and Parts

Thu Nov 27 08:12:42 EST 2008

Nimesh Muley wrote:
> Hi,
>
> What might be possible in 5.1? Ability to plug-in custom Resource implementation or a resource implementation that will look into repository. I hope the former is available in 5.0 :-).
>   
The repository publishes artifacts on a web url, so the UrlResource 
loader will handle those. I was referring to custom loaders, like from a 
database.
> I understood the resource configuration part.
>
> Would it make sense to have Knowledge Builder configuration on lines of resource being part and Knowledge Builder being whole?
>   
typicaly one added xml composition == one knowledge base. But that won't 
be enforced, you can added multiple xml composition files.
> Typically for executing any business functionality we have more than one resources involved. This may happen due to splitting of rules based on different sub features but wanting to execute the top level feature (basically easy maintainability). Or it could be pure dynamism needed during execution. With this typical usage in mind I feel that having a Knowledge Builder level configuration may help in maintenance of executable rules.
>   
You will be able to mix and math programmtic api addition, with xml 
composition additions.

Mark
> Regards,
> - Nimesh
>
>
> -----Original Message-----
> From: rules-dev-bounces at lists.jboss.org [mailto:rules-dev-bounces at lists.jboss.org] On Behalf Of Mark Proctor
> Sent: Thursday, November 27, 2008 2:05 PM
> To: Rules Dev List
> Subject: Re: [rules-dev] Knowledge Composition and Parts
>
> Nimesh Muley wrote:
>   
>> Hi,
>>
>> To load a resource from DB would someone need to provide a custom implementation of Resource (meant for DB lookup) and then use it in the KnowledgeBuilder? Can this definition be later extended to load a resource from a repository once repository concept is there during execution time (similar / same as what is available at definition time)?
>>
>>     
> This might be possible, I'll bear it in mind as an enhancements for 5.1.
>   
>> Should resource configuration at Resource level (part) or at KnowledgeBuilder? As per my understanding of the definition below, it seems more apt at KnowledgeBuilder level.
>>
>>     
> If you look at the javadocs for drools-api ResourceConfiguration is
> specific to what you are loading, for instance with decision tables (the
> only place where it is currently used) it provides the binary type, XLS
> or CSV, and optionally the worksheet name.
>
> Mark
>   
>> Regards,
>> - Nimesh
>>
>>
>> -----Original Message-----
>> From: rules-dev-bounces at lists.jboss.org [mailto:rules-dev-bounces at lists.jboss.org] On Behalf Of Mark Proctor
>> Sent: Thursday, November 27, 2008 12:01 PM
>> To: Rules Dev List
>> Subject: [rules-dev] Knowledge Composition and Parts
>>
>> I'm in the process of doing the final changes to drools-api. Having done
>> the spring work, not yet committed, I liked their resource framework, so
>> decided to copy this for Drools. So we now have:
>> KnowledgeBuilder.add( Resource, KnowledgeType, ResourceConfiguration );
>>
>> Where we support the following Resource sources:
>> FileSystemResource, ClassPathResource, UrlResource ByteArrayResource,
>> ReaderResource, EncodedResource and InputStreamResource
>>
>> In use it'll look like:
>> kbuilder.add( ResourceFactory.newClassPathResource( "somefile.drl",
>> classLoader ), KnowledgeType.DRL )
>>
>> I do not yet do knowledge type inference from the .ext - I think I'll
>> leave that till after 5.0, if I do it at all.
>>
>> So kbuilder.addResource( URL, ...) and kbuilder.addResource( Reader, ...
>> ) from M3 no longer exist and are as above.
>>
>> What I'm adding now is the ability to provide an xml file that is a
>> configuration of resources to load. The term Configuration is
>> overloaded, and we use this more to provide the directives for
>> knowledgebuilder and knowledgebase. So I was thinking Composition and
>> Part - for Knowledge Composition and Knowledge Part, from dictionary.com
>> on "composition":
>> "the act of combining parts or elements to form a whole."
>> "the composition of "aircraft" from "air" and "craft."
>>
>> My reasoning for this is a composition will contain rules, processes,
>> decision tables, dsls etc. "The KnowlegeBase is a composition of
>> Knowlege Parts".
>>
>> The XML would look like:
>> <composition>
>> <part resource="classpath://........" type="DRL">
>>
>> <part resource="file://........">
>> <decisiontable-configuration type="XLS" worksheet-name="blah" />
>> </part>
>> </composition>
>>
>> I have not added a resource type attribute, as we will assume it must
>> start with protocol. classpath will use ClassPathResource, file will use
>> FileSystemResource and anything will be a UrlResource. This would be a
>> special KnowlegeType. I may later make the type optional, once we can
>> infer the type from the .ext.
>> kbuilder.addResource( ResourceFactory.newFileResource(
>> "/data/my-knowledge.xml" ), KnowledgeType.COMPOSITION );
>>
>> What do people think?
>>
>> Mark
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> MASTEK LTD.
>> Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List.
>> In the US, we're called MAJESCOMASTEK
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server.
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>     
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> MASTEK LTD.
> Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List.
> In the US, we're called MAJESCOMASTEK
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081127/5c4295eb/attachment.html