I tried implimenting this change, and 2 test cases fail. They look like
they are failing exactly in the case where the result specification has
a TypeOrFeature with a specified type other than "x-unspecified", and
the containsTypeOrFeature method is being called using the form which
doesn't pass in an explicit type, so is being treated as if
x-unspecified was passed in.
As discussed below, this should give "false", but the text cases expect
true.
Should I change the test cases? The failing ones are:
ResultSpecification_implTest: It defines a result spec containing the
type "FakeType" for languages "en", "de", "en-US", "en-GB", but not
"x-unspecified". So the call rs.containsType("FakeType") returns false,
but the test says it should return true (because the set of languages
for FakeType is missing x-unspecified).
The other test is the PearRuntimeTest.
This test loads two Pears, runs them and then looks at the CAS result.
The descriptor for one of the tests, the TutorialDateTime descriptor
says it output 3 types, *but for language "en"* (only, and not for
x-unspecified in particular).
The result spec built for the aggregate is empty (the test case has
nothing specified here).
When it is passed down to the delegates, the setResultSpecification for
the Pear descriptor in PearAnalysisEngineWrapper is called. This is not
implemented, so it inherits from its super, which is
AnalysisEngineImplBase - and this impl does nothing (expecting to be
overridden). I'll write this up as a Jira issue.
But even if this were "fixed", because the outer Aggregate had nothing
specified in its capability, the inner primitive analysis engine is set
up initially with a "default" result spec, which is its own output
capabilities. This spec says it should produce results just for "en",
and in particular it should *not* produce output for x-unspecified.
This annotator is written to respect the result spec, so it doesn't
produce anything.
Anyone object to my changing the test cases?
-Marshall
Marshall Schor wrote:
Language specifications are in a hierarchy. For example, from most
inclusive to finer subsets, we have:
x-unspecified
en
en-us
A result spec's most common use is in a negative sense - Annotators
can check a result spec and if it doesn't contain the type or feature,
it can skip producing that type or feature.
For simplicity, let's consider we have only one type or feature,
called TF.
If the annotator thinks it produces TF for language en-us only, and
wants to check if should skip producing this, it calls
containsType/Feature(TF, "en-us"). This is defined in the current
impl to return true, if the result spec has languages x-unspecified,
en, or en-us.
Let's consider the opposite case. Suppose we have an annotator that
can produce TF for "en". Suppose the result-spec has an entry for TF
only for the language "en-us". Should that annotator produce
results? If it calls containsType/Feature(TF, "en"), it will get a
"false" (current implementation).
After some thinking about this and some discussion (because I don't
think I got it right, just by myself :-) ),
it seems that this is correct. Consider the following case:
The language of the document is "en", and the containing (top-most)
aggregate specified explicitly it wanted
output only for en-us. In that case, the annotator should not
produce any results, because the language
of this doc is not en-us, and the assembler put together things that
they said should only output en-us results.
This same logic seems to apply to x-unspecified:
Suppose we have an annotator that can produce TF for "x-unspecified".
Suppose the result-spec has an entry for TF only for the language
"en". Should that annotator produce results? If it calls
containsType/Feature(TF, "x-unspecified"), it should get a "false"
(broken in the current implementation!, but was true I think in the
previous one).
Assume the language of the document is "x-unspecified", and the
containing (top-most) aggregate specified explicitly it wanted
output only for en. In that case, the annotator should not produce
any results, because the language
of this doc is not "en", and the assembler put together things that
they said should only output "en" results.
Do others agree with this?
-Marshall
