Re: Update to MQM documentation and one question

Am 28.06.13 18:39, schrieb Arle Lommel:
> [Responding to two mails here, starting with Dave and then Felix.]
>
> Hi Dave,
>
>> This makes a lot of sense. I'd support this approach.
>
> Unless someone objects

I do :)


> , let me see what I can formalize using this approach then.

I would propose that you continue with the mapping in an approach 
independent of the way how to represent the MQM information in (ITS 2.0) 
markup. That will allow us to discuss these two items separately. Would 
that work?

Best,

Felix

> I'll write up an MQM use case that uses <span>s for now. We can deal 
> with the other complexity later.
>>
>> So is it this case the current mappings from ITS LQI types to MQM 
>> types would be purely informative and not really a best practice 
>> recommendation right?
>
> Well, we could have a normative mapping from LQI to the full MQM set, 
> but MQM is really a descriptive language, so if you have an MQM metric 
> that uses only six issue types, the normative mapping at the high 
> level doesn't help you know what to do with that particular MQM 
> metric. The normative mapping is more useful going the other way: it 
> tells you how to treat those MQM issue types in ITS 2.0.
>
>> This is because, as i now understand it, people should be free for 
>> example to use MQM mistranslation with ITS LQI terminology as long as 
>> they provided a description of this usage that LQI profile ref can 
>> point to?
>
> Not sure I follow what you mean here. I see to possibilities: if you 
> mean that you could map MQM /Mistranslation/ to LQI /terminology/, no, 
> you shouldn't do that. The mappings are not infinitely malleable. They 
> still have to make sense. And here is where the MQM→LQI mapping is 
> handy, to make sure you get that right.
>
> The only real complexity comes from what to do if you have an LQI 
> issue type like /internationalization/ but your MQM metric has no 
> equivalent in its selection of issue types. To be clear, you could 
> have an MQM metric with these issue types:
>
>
> In this case, what do you do when mapping from LQI to MQM and you have 
> LQI /internationalization/ in your document? There is no way to map 
> that to this particular MQM metric. (The MQM superset, however, has 
> /Internationalization/, but it isn't used in /this/ metric.)
>
> I don't think we can provide guidance for that scenario, other than to 
> say that for a particular MQM metric you may have no expressive power 
> for an issue in LQI and it should be ignored. But that is a problem 
> with consuming data, not producing it, so it doesn't change what has 
> to be done with ITS or the markup (because in such a case a 
> /different/ tool/metric was used to generate the data and the problem 
> is for a specific MQM metric and how it deals, or doesn't, with 
> extraneous categories).
>
>
>> I've not considered the overlapping/non-contiguous issue in any 
>> depth, but my gut feeling is that this isn't something ITS can solve, 
>> but is there anything in the XLIFF inline mark-up work that could 
>> help? Or perhaps TEI? Aligning/stealing from an existing standard is  
>> preferable to a new solution in this edge case.
>
> Agreed. This will need some more attention. Hans U. suggested NIF as 
> well, but agreed that recalculating offsets makes this a nonstarter.
>
>> Concerning the description, I don't know if any partner implementing 
>> LQI would be interesting in defining their use of it in terms of MQM 
>> in a public page as a reference example? Phil, Pedro?
>
> Would be nice.
>
> *******
>
>> Hi Arle, all,
>>
>> using locQualityIssueComment or locQualityIssueProfileRef sounds like 
>> overloading and will prevent using locQualityIssueProfileRef for 
>> other purposes. If e.g. somebody defines a profile of MQM, how would 
>> you identify that?
>
> I actually think it isn't overloading it. The base URI would point to 
> the profile declaration (that profile could, conceivably, be the full 
> set) and the anchor would point to the issue in that specific profile. 
> But I can see why you might disagree and think that adding the anchor 
> is going too far.
>
>
>> Also, I would still hope that we aim to map ITS types and MQM types - 
>> but if MQM types are represented as a profile, how will that work?
>
> I don't think it changes anything, but see my note above in response 
> to Dave. Because MQM is an expressive vocabulary for building metrics, 
> we will run into cases where data loss will arise going from LQI to a 
> /specific/ MQM profile. No way to escape that.
>
>>
>> Finally, looking at the mapping topic and the representation at
>> http://www.w3.org/International/its/wiki/Localization_quality_types_mappings#Mapping_to_MQM
>> I was reminded of mapping work I did in a different context, see
>> http://www.w3.org/TR/mediaont-10/
>> and as an example
>> http://www.w3.org/TR/mediaont-10/#youtube-table
>> Maybe it would make sense to adopt from above approach the "relation 
>> column" (with the values exact, more general, more specific, related, 
>> N/A)? It has the advantage that a formal representation of the 
>> mapping is possible (though not needed).
>
> I'll look into this. No time at the moment, but on Monday, perhaps we 
> can discuss internally.
>
>> I agree that discussing these issues would be great.
>
> Wednesday would be good.
>
> -Arle