Ok, perfect.

While we further check over the configuration content part, I've
implemented a sample that wraps the ContentItem in a ContentItem bag which
contains also a configuration dictionary:
 - ContentItemBag:
https://github.com/insideout10/stanbol-facade/blob/master/stanbol-facade-api/src/main/java/io/insideout/stanbol/facade/models/ContentItemBag.java

The wrapper is fed via the enhancementJobManager:
 -
https://github.com/insideout10/stanbol-facade/blob/master/stanbol-facade-api/src/main/java/io/insideout/stanbol/facade/services/TaskService.java

This is a sample service which dumps the configuration parameters:
 -
https://github.com/insideout10/stanbol-facade/blob/master/stanbol-facade-api/src/main/java/io/insideout/stanbol/facade/engines/ContentItemBagSpyEngine.java

In the above examples the content to be lifted and and the configuration
parameters are encapsulated in a JSON request (converted to a TaskRequest)
such as this:

{
"configuration": {
"configuration.parameter.1": "value.1",
"configuration.parameter.2": "value.2"
},
"mimeType": "application/rdf+xml",
"content": " ... "
}

The above can of course be changed as soon as we define the content part
for the per-call configuration of engines.

BR,
David


On Mon, Dec 10, 2012 at 5:51 PM, Fabian Christ <[email protected]
> wrote:

> Hi,
>
> maybe we could define a specific content part [1] for such config
> information. This way we do not have to change the interface at all. It is
> just a matter of filling a to be defined "config content part".
>
> Then we have to write a simple engine that takes config params from an
> incoming request and writes this information into the config content part.
> Engines can look up the config per request from the config content part.
>
> Maybe Rupert can say more about this as he has defined the content part
> infrastructure.
>
> [1]
> https://stanbol.apache.org/docs/trunk/components/enhancer/contentitem.html
>
>
> 2012/12/10 David Riccitelli <[email protected]>
>
> > Thanks Fabian,
> >
> > Yes, I am thinking in the context of the engines that we're contributing,
> > but it could be useful for the existing engines as well.
> >
> > Currently the engines only rely on a provided ContentItem instance for
> the
> > enhancement process (computeEnhancements(ContentItem ci)): maybe the
> > ContentItem interface could be extended to include a reference to a
> > configuration map.
> >
> > Engines that support custom configurations will look-up from this map for
> > per-call configurations. This would not affect existing engines, but
> would
> > enable them to use this feature in the future.
> >
> > What do you think?
> >
> > David
> >
> >
> > On Mon, Dec 10, 2012 at 5:37 PM, Fabian Christ <
> > [email protected]
> > > wrote:
> >
> > > Hi,
> > >
> > > are you referring to existing engines in Stanbol or are you using your
> > own
> > > ones?
> > >
> > > At the moment we do not support such a concept of per request configs.
> At
> > > least the current engines do not look in the ContentItem for their
> > config.
> > >
> > > We have another requirement to make it possible to pass existing
> metadata
> > > into the request and send text plus existing metadata to Stanbol. Maybe
> > > such config per request could be a similar case.
> > >
> > > Anyway, currently it is not yet supported out of the box IIRC.
> > >
> > > Best,
> > >  - Fabian
> > >
> > >
> > > 2012/12/10 David Riccitelli <[email protected]>
> > >
> > > > Hello,
> > > >
> > > > We have a need to allow passing some engine configuration parameters
> in
> > > > each call.
> > > >
> > > > For example, we might want for one call to have confidence score >
> 0.5,
> > > and
> > > > for another call > 0.9 (just making up the numbers).
> > > >
> > > > Is this feasible now? Can the per-call configuration parameters be
> > bound
> > > to
> > > > the ContentItem? If yes, how?
> > > >
> > > > Thanks,
> > > > David
> > > >
> > > > --
> > > > David Riccitelli
> > > >
> > > >
> > > >
> > >
> >
> ********************************************************************************
> > > > InsideOut10 s.r.l.
> > > > P.IVA: IT-11381771002
> > > > Fax: +39 0110708239
> > > > ---
> > > > LinkedIn: http://it.linkedin.com/in/riccitelli
> > > > Twitter: ziodave
> > > > ---
> > > > Layar Partner Network<
> > > >
> > >
> >
> http://www.layar.com/publishing/developers/list/?page=1&country=&city=&keyword=insideout10&lpn=1
> > > > >
> > > >
> > > >
> > >
> >
> ********************************************************************************
> > > >
> > >
> > >
> > >
> > > --
> > > Fabian
> > > http://twitter.com/fctwitt
> > >
> >
> >
> >
> > --
> > David Riccitelli
> >
> >
> >
> ********************************************************************************
> > InsideOut10 s.r.l.
> > P.IVA: IT-11381771002
> > Fax: +39 0110708239
> > ---
> > LinkedIn: http://it.linkedin.com/in/riccitelli
> > Twitter: ziodave
> > ---
> > Layar Partner Network<
> >
> http://www.layar.com/publishing/developers/list/?page=1&country=&city=&keyword=insideout10&lpn=1
> > >
> >
> >
> ********************************************************************************
> >
>
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>



-- 
David Riccitelli

********************************************************************************
InsideOut10 s.r.l.
P.IVA: IT-11381771002
Fax: +39 0110708239
---
LinkedIn: http://it.linkedin.com/in/riccitelli
Twitter: ziodave
---
Layar Partner 
Network<http://www.layar.com/publishing/developers/list/?page=1&country=&city=&keyword=insideout10&lpn=1>
********************************************************************************

Reply via email to