stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dileepa Jayakody <dileepajayak...@gmail.com>
Subject Re: [GSoC] [Update] FOAF Co-reference based Entity Disambiguation in Stanbol
Date Thu, 26 Sep 2013 11:36:32 GMT
Hi All,

I have attached the source files to the jira :
https://issues.apache.org/jira/browse/STANBOL-1161

Thanks,
Dileepa


On Thu, Sep 26, 2013 at 4:52 PM, Dileepa Jayakody <dileepajayakody@gmail.com
> wrote:

> Thanks a lot for your feedback Rupert.
>
>
> On Thu, Sep 26, 2013 at 4:44 PM, Rupert Westenthaler <
> rupert.westenthaler@gmail.com> wrote:
>
>> Hi Andreas
>>
>>
>> On Tue, Sep 17, 2013 at 1:28 PM, Andreas Kuckartz <a.kuckartz@ping.de>
>> wrote:
>> > Dileepa Jayakody:
>> >> I have successfully implemented and tested the foaf disambiguation
>> engine
>> >> with the help of Stanbol community including Rupert, Rafa and Andreas.
>> >
>> > +1 and thanks to Rupert and Rafa from here as well !
>> >
>>
>> From my viewpoint working with Dileepa and Antonio was very rewarding.
>> Thanks for all the hard work both of them put into their GSoC
>> projects.
>>
>> >> Please have a look at the disambiguation-foaf engine, try it out and
>> give
>> >> your comments for improvements. I appreciate your advice very much.
>> >> I shall also create a Stanbol Jira with all details and attach the
>> >> source-code and built bundle after finalizing the project.
>> >
>>
>> I had a look at the source. IMO using the 'connectnes' of an entity
>> with suggested one is something that should work well for any schema
>> and is not just limited to FOAF.
>
>
> +1. It doesn't necessarily have to be FOAF. The URI-reference type
> properties of any schema/vocabulary can be evaluated for connectedness by
> processing correlated links.
>
>> In addition doing so should be
>> relatively cheap (in comparison to calculating shortest paths as dome
>> by the engine implemented by Antonio). In addition it can also work
>> for entities originating from different vocabularies (if they refer
>> some common resources) and does not require users to build up special
>> index structures (as it can directly work on the relations in the
>> vocabulary).
>>
>> To give a concrete example I could image to use such an engine to
>> disambiguate persons with the same name but related to different
>> companies as define within an CRM management system of a company.
>>
>> +1
>
>> > What do others think regarding inclusion of Dileepa's engine in Apache
>> > Stanbol ?
>> >
>>
>> Thats the goal. For that Dileepa you will need to attach the source of
>> your engine as attachment to STANBOL-1161. After that I can add your
>> code to the Stanbol SVN (most likely to a branch where we can make
>> further adaptions before including it to the trunk).
>>
>> Yes, I will do so and continue working with the community to imrove the
> engine.
>
>
>> Also note that there is also the freebase disambiguation engine from
>> Antonio (STANBOL-1157) and I also noticed that both the foaf and the
>> freebase disambiguation engine do share some code with the
>> disambiguation-mlt engine. So maybe it would be the best to create a
>> branch with all this disambiguation engines and try to extract some
>> cross cutting functionalities to a common module. First candidates of
>> such functionalities would be a Java API for representing
>> disambiguation relevant data extracted from present
>> fise:TextAnnotation and their suggestions (fise:EntityAnnotation) or a
>> API for defining disambiguation contexts (such as sliding windows).
>>
>> +1. We realized that many engines require to work with common
> abstractions for fist:EntityAnnotation and fise:TextAnnotation. Therefore
> it will be helpful to developers if can build such common building blocks
> as APIs.
>
> Looking fwd to work more on Stanbol on these parts.
>
> Thanks,
> Dileepa
>
>>
>> best
>> Rupert
>>
>>
>> --
>> | Rupert Westenthaler             rupert.westenthaler@gmail.com
>> | Bodenlehenstra├če 11                             ++43-699-11108907
>> | A-5500 Bischofshofen
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message