Re: issue-60 (Re: Comment on ITS 2.0 specification WD)

The other alternative is that we expand the semantics of "uncategorized" slightly to allow for a more naturalistic interpretation such that it doesn't mean "we haven't categorized it" to "we haven't or can't categorize it". That would be satisfactory as well, I think, and less of a change.

-Arle


On 2012 Dec 11, at 18:27 , Arle Lommel <arle.lommel@dfki.de> wrote:

> Jörg is correct here that nothing has this already. This is really looking forward to QT Launchpad work. If saying "nobody has implemented this so far" disqualifies it, then we would be forced to use "uncategorized" and add some custom markup. That wouldn't be the end of the world for us, but it would be nice to have.
> 
> However, see my last mail about how I see this as different.
> 
> (I can say, up front, that if this isn't accepted I won't hold anything up over it, so the moment this causes real problems, we can drop it.)
> 
> -Arle
> 
> On 2012 Dec 11, at 18:15 , Jörg Schütz <joerg@bioloom.de> wrote:
> 
>> Hi Felix,
>> 
>> Since an additional value doesn't actually harm the type list which certainly can be seen as open ended (but still backward compatible), the need for a subsequent LC is questionable.
>> 
>> Nevertheless, the proposed quality type value "unintelligible" for the described output case might be controversial because it does not indicate/reflect a quality consideration as the other types in the list do. The QT Launchpad project should therefore consider to use "uncategorized" because this value might indicate the "trashy" quality.
>> 
>> And TMK, I'm not aware of any language proofing technology that uses "unintelligible" has a quality value.
>> 
>> Cheers -- Jörg
>