W3C home > Mailing lists > Public > public-i18n-its-ig@w3.org > March 2014

RE: MT Confidence mapping to XLIFF 2

From: Yves Savourel <ysavourel@enlaso.com>
Date: Sun, 23 Mar 2014 07:55:30 -0600
To: <public-i18n-its-ig@w3.org>
Message-ID: <00f801cf469f$8f9f9b60$aeded220$@com>
Hi Felix, all,

> Any chance to convince the XLIFF tc to use 0-1, like ITS2?
> What is the rationale behind the different value?

I suppose it's consistent for the other types of scores (similarity, qualitySuotability, etc.) which have been 0-100 traditionally.

I don't think the range is the big issue.
The problem is the impossibility for ITS to use anything but its:mtConfidence for that data category.
I wish I had noticed this before.

I guess we have to look at this from a pragmatic viewpoint: are we going to have many ITS-only processor looking at XLIFF2 files? If
the main concern is to be sure XLIFF2 processor can work with ITS2, then maybe the requirement for a global rule may be lifted for
that occurrence? And itsx:mtConfidencePointer provided as a fall back.

Any thoughts David?

-ys


-----Original Message-----
From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Sunday, March 23, 2014 6:48 AM
To: Yves Savourel
Cc: public-i18n-its-ig@w3.org
Subject: RE: MT Confidence mapping to XLIFF 2

Hi Yves, J÷rg, all,

> Hi J├Ârg,
>
> Thanks for the suggestion. But while the annotatorsRef should be used 
> to specify the agent doing the annotation, I'm not sure how an ITS 
> processor could use it to map the value from matchQuality: one could 
> identify the tool and assume an implicit mapping, but normally ITS 
> uses global rules to indicate that type of information.
>
> For example:
>
> <its:langRule selector="//p" langPointer="@mylangattribute"/>
>
>  says to the ITS processor that the attribute mylangattribute in the 
> <p> element is the same as xml:lang.
>
> We would need something like:
>
> <its:mtConfidenceRule selector="//mtc:match"
> mtConfidencePointer="@matchQuality"/> (and "@matchQuality" should 
> really be some kind of XPath expression that divides the value of 
> matchQuality by 100).

That would be "@matchQuality div 100". You could implement that in a non standard manner with "itsx:mtConfidencePointer" - but if we
want to recommen this for the XLIFF <> ITS mapping, it's probably not a good idea.

>
> Now, this is only if we want to always have a valid ITS rule useable 
> by ITS-only processors in XLIFF documents. So far all the mappings we 
> have respect that.

Makes sense to me, hard to achieve in a standard way for XLIFF2 <> ITS2 here.

>
> Note also that, technically, we can't really use its:mtConfidence 
> directly in XLIFF2 either because an extension or a module (I quote 
> [1]): "...MUST NOT provide the same functionality as an existing XLIFF 
> core or module feature, ..." And matchQuality is certainly providing 
> same functionality as its:mtConfidence (even the note in section 
> 5.1.6.2 give that as an example in the note: "... a Machine 
> Translation self-reported confidence score."

Any chance to convince the XLIFF tc to use 0-1, like ITS2? What is the rationale behind the different value?

Best,

Felix

>
> Cheer,
> -yves
>
> [1]:
> http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#
> ext-constraints
>
>
>
> -----Original Message-----
> From: J├Ârg Sch├╝tz [mailto:joerg@bioloom.de]
> Sent: Saturday, March 22, 2014 10:13 AM
> To: public-i18n-its-ig@w3.org
> Subject: Re: MT Confidence mapping to XLIFF 2
>
> Hi Yves,
>
> What about using the annotatorsRef/its-annotators-ref attribute for 
> this purpose, i.e. to provide additional information as foreseen in 
> the MT Confidence specification?
>
> Cheers -- J├Ârg
>
> On Mar 22, 2014 at 14:53 (CET), Yves Savourel wrote:
>>> ...and there is no way to even declare qualityMatch as the holder 
>>> for the mtConfidence value because there is no mtConfidenceRef 
>>> attribute on the mtConfidenceRule element.
>>
>> Correction: I meant mtConfidencePointer not mtConfidenceRef
>>
>> -ys
>>
>
>
>
>
Received on Sunday, 23 March 2014 13:56:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:11:30 UTC