Hi Rupert
I tried the two options but I have some doubt:
1) Short option
get the CELI engine bundle and install it to a recent Stanbol 0.10.0 launcher:
install means copy il place of {trunk}/enhancer directory?
2) Complete workflow
what you mean with "check out the branch [1]" in the complete workflow list? Do
I need to substitute {trunk}/enhancer directory with
{branch}/celi-enhancement-engines directory?
thanks
Alessandra
Il giorno 24/mag/2012, alle ore 11.58, Rupert Westenthaler ha scritto:
> Hi
>
> Am 24.05.2012 um 08:50 schrieb Alessandra Donnini <[email protected]>:
>
>> Are the new CELI enhancement engines available in the last release
>> apache-stanbol-0.9.0-incubating (2012/05/08) available in
>> http://incubator.apache.org/stanbol/downloads/releases.html?
>> Do I need to download files from
>> https://issues.apache.org/jira/browse/STANBOL-583 and install them? If so
>> how should I do?
>> thanks
>> Alessandra Donnini
>>
>
> Currently the plan is to include The CELI engines only in 0.10.0.
> The engines are not yet included in the trunk, but available in a branch [1]
> as there are still two remaining issues with the NER engine. If those are
> solved the engines should be included in the trunk within days.
>
> To use the CELI engines in the current state you will need to
>
> Short option (should work)
>
> * check out the branch
> http://svn.apache.org/repos/asf/incubator/stanbol/branches/celi-enhancement-engines/
> * call mvn install in the branch
> * get the CELI engine bundle and install it to a recent Stanbol 0.10.0
> launcher
>
> The complete workflow would be to
>
> * check out and "mvn install" the trunk
> * check out the branch [1]
> * call mvn install in the branch
> * go back to {trunk}/launchers/full
> * call mvn clean install - this will create a full launcher that includes the
> bundles as build in the branch
> * use this launcher to start Stanbol
>
> best
> Rupert
>
> [1]
> http://svn.apache.org/repos/asf/incubator/stanbol/branches/celi-enhancement-engines/
>
>>
>>
>>
>> Il giorno 24/mag/2012, alle ore 08.18, Rupert Westenthaler ha scritto:
>>
>>> Hi all,
>>>
>>> In the last two weeks I considerable improved the validation of the
>>> Enhancements created by the different Stanbol Enhancement Engines.
>>> Here is the list of related issues:
>>>
>>> * STANBOL-613: Define how to retrieve the language of the parsed content
>>> * STANBOL-617: Define how to encode fise:TopicEnhancements
>>> * STANBOL-625: Add link to the entityhub:site if suggested Entity is
>>> available via the Entityhub
>>>
>>> Note also STANBOL-612 - providing a utility class that easily allows
>>> to validate created enhancements in unit tests of EnhancementEngines.
>>> All existing engines do now use this utility to validate Enhancements.
>>> This is also true for the contributed CELI engine (STANBOL-583)
>>> already confirm to those tests.
>>>
>>> The next think I would like to make more clear (and easier to
>>> use/understand) is how confidence is represented for Stanbol
>>> Enhancements. Related to this I would like to discuss the following
>>> two suggestions:
>>>
>>> ### Suggestion 1: Require confidence values to be in the range [0..1]
>>>
>>> This is an long going discussion, but I would really like to add a
>>> check that enforces confidence values to be in the range between
>>> [0..1].
>>>
>>> I think this change is necessary, because it moves the responsibility
>>> for interpreting confidence values from the Stanbol users to the
>>> implementors of the Engines. I know that providing confidence values
>>> is a hard thing to do, but while it may be hard for Engine developers
>>> it is near to impossible to Stanbol users to do so.
>>>
>>> Note that EnhancementEngine would still be free to create Enhancements
>>> with no "fise:confidence" value.
>>>
>>> Surprisingly a lot of the existing Engines do already confirm to this
>>> rule. The most prominent exception is the Named Entity Tagging Engine
>>> (o.a.s.enhancer.engine.entitytagging). Because of this I implemented
>>> already an algorithm that normalizes confidence values by a
>>> combination of the levenshtein distance (selected-text <-> entity
>>> label) and the Solr result score for the Entity (see STANBOL-624 for
>>> details).
>>>
>>> If we could agree to this rule I would use a similar approach also for
>>> other Engines that do not yet normalize confidence values between
>>> [0..1]
>>>
>>> ### Suggestion 2: Add fise:confidence-level property
>>>
>>> The "confidence-level" is intended to make it easier for clients to
>>> decide how to process Enhancements. It would not use a numerical range
>>> but four distinct values:
>>>
>>> * confident: Meaning that a match is very likely - indicating that
>>> those annotations typically can be accepted automatically (e.g. If the
>>> EntityLinking engine finds a single Entity that exactly matches the
>>> text selected by an text annotation)
>>> * ambiguous: Meaning that there are several possibilities but is is
>>> still likely that one of them match (e.g. Paris, Paris (Texas))
>>> * suggestion: Meaning that the match is not completely certain, but
>>> there are not several options (e.g. Germans -> Germany)
>>> * uncertain: Meaning that Entities do match, but the probability of a
>>> match is rather speculative (e.g. John -> Elton John)
>>>
>>> IMHO using this classification would fit a lot of engines much better
>>> as the numeric "fise:confidence" property as it does not rise the
>>> expectation in users that confidence values are on a rational scale
>>> (e.g. a Enhancement with a confidence of "0.8" is not two times as
>>> likely as one with "0.4").
>>>
>>> Engines would have the possibility to manually add those information
>>> to enhancements. For enhancements that do not define those we could
>>> implement an post-processing engine that adds those based on generic
>>> rules.
>>>
>>> e.g.
>>>
>>> * ignore Enhancements with an existing "confidence-level" assignment
>>> * TextAnnotations with a confidence value > 0.8 => confident
>>> * TextAnnotations with a confidence value < 0.8 > 0.5 => suggestion
>>> * TextAnnotations with a confidence value < 0.5 => uncertain
>>> * TextAnnotations with a single linked EntityAnnotation with a
>>> confidence > 0.8 => confident
>>> * TextAnnotations with a several linked EntityAnnotation with a
>>> confidence > 0.8 => ambiguous *)
>>> * TextAnnotations with several linked EntityAnnotations with a
>>> confidence > 0.5 but no one > 0.8 => ambiguous *)
>>> * TextAnnotations with a single linked EntityAnnotation with a
>>> confidence < 0.8 > 0.5 => suggestion
>>> * TextAnnotations with EntityAnnotations with confidence values < 0.5
>>> => uncertain
>>> * TopicAnnotation with a confidence value > 0.8 => confident
>>> * TopicAnnotation with a confidence value < 0.8 > 0.5 => suggestion
>>> * TopicAnnotation with a confidence value < 0.5 => uncertain
>>>
>>> *) NOTE that in those cases only EntityAnnotations with a confidence
>>> value > 0.5 would be marked as "ambiguous". Additional
>>> EntityAnnotations with confidence values < 0.5 would be marked as
>>> "uncertain"
>>>
>>> The values '0.8' and '0.5' should be configurable.
>>>
>>> Note that "fise:confidence-level" could be also used by Engines that
>>> can not provide fise:confidence values (E.g. the langid engine could
>>> mark detected languages as "uncertain" if the parsed text was to
>>> short).
>>>
>>> WDYT
>>> Rupert
>>>
>>>
>>> --
>>> | Rupert Westenthaler [email protected]
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>
