Mailing-List: contact stanbol-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stanbol-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olivier.grisel@gmail.com
 designates 209.85.216.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:from:date
         :x-google-sender-auth:message-id:subject:to:cc:content-type
         :content-transfer-encoding;
        b=fLK/5cjxg76W2z+sKNdWRMkGquN7jP6AeupRicZM0+RBHu7lhbRHnWVnkOTCqL0mU+
         DlCvI/xOIgryU61nS3IZWkEV4Ruf2WErvAlYVMVdlXE/Iq2EwWYD+qcnHYeg3D2pxNbN
         PFltiCIKlaZ5z2RgrHs8Fk1zveSm8zyf6NJJY=
MIME-Version: 1.0
Sender: olivier.grisel@gmail.com
In-Reply-To: <AANLkTimJekfmh50+LnH5BHcbFA2TZrLdKf1AeSqcpC7N@mail.gmail.com>
References: <AANLkTinHmV6aSNBy8x6vkYjK44B7zCebTrFJ1yJYmMkT@mail.gmail.com>
 <AANLkTinc13FOp4x9XOQEfxUkuwTXT=GtnPWaCc2Eku5x@mail.gmail.com>
 <AANLkTik3nsXiwark1XshXDjrPeBAt=gy5h7cOn1wk71k@mail.gmail.com>
 <AANLkTimObsFyDZ4WQNN-ny8W37R_froE+EknkDODfQcd@mail.gmail.com>
 <AANLkTikKpR-fx++knoPMp3CiXV++h0Gzm90kJn7DaiOH@mail.gmail.com>
 <AANLkTin_WwJfKPArOVTsWbBfmQaUxKVpBNocJM9qVXmS@mail.gmail.com>
 <AANLkTimJekfmh50+LnH5BHcbFA2TZrLdKf1AeSqcpC7N@mail.gmail.com>
From: Olivier Grisel <olivier.grisel@ensta.org>
Date: Mon, 7 Mar 2011 14:22:17 +0100
Message-ID: <AANLkTikMPGUpMiMYAqq=D3KLmQE1knF+JP+1mFg+k3N7@mail.gmail.com>
Subject: Re: Stanbol Enhancement Structure (discussion)
To: stanbol-dev@incubator.apache.org
Cc: Rupert Westenthaler <rupert.westenthaler@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2011/3/7 Rupert Westenthaler <rupert.westenthaler@gmail.com>:
> On Mon, Mar 7, 2011 at 12:17 PM, Olivier Grisel
> <olivier.grisel@ensta.org> wrote:
>> 2011/3/7 Rupert Westenthaler <rwesten@apache.org>:
>>>
>>> or (3) force implementors of EnhancementEngines to add both
>>> sb:Annotation and sb:EntityAnnotation as rdf:type.
>>>
>>> All this three Solutions do not seam very promising because
>>> =C2=A0- users will not want to enable reasoning
>>> =C2=A0- UNIONS do make queries very complex, and what happens if we add=
 an
>>> other Annotation type?
>>> =C2=A0- adding multiple rdf:types would be nice solution for the client
>>> side, but has the danger that some functionality will break if an
>>> EnhancementEngines does not add the additional type.
>>
>> I agree we should not impose UNIONS of rdfs reasoning to the client
>> side. I had solution 3 in mind: every time you add an annotation that
>> is about the identification of an Entity in the text (as opposed to
>> the time of annotations such as finding the topic of the content item,
>> the language, a keyphrase, ...), the enhancement engine should add
>> both rdf:type sb:Annotation and rdf:type sb:EntityAnnotation. If it
>> does not it's considered a bug and has to be fixed.
>>
> If we aim in that direction, we should create a test framework as part
> of the Stanbol Enhancer. EnhancementEngines would than need to pass
> all the tests defined by this Framework.
> I think it should not be hard to write simple unit tests that check if
> Enhancements created by EnhancementEngines are in line with the
> Enhancement Structure.

+1 We will also update the Java helpers to generate annotations that
are consistent with the model.


--=20
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel