Re: Update to MQM documentation and one question

On 26/06/2013 07:38, Lieske, Christian wrote:
> Furthermore, a comment about granularity and losslessness might be cool (for all columns, not just MQM). Example: The MQM categories for terminology are more granular than the ones of ITS. Thus, going from MQM to ITS always results in a loss of information. This to a certain degree can for example be mitigated by using the its:locQualityIssueComment as follows its:locQualityIssueComment="MQM original value was 'X'".

Hi Christian, Arle, others,
Using the its:locQualityIssueComment to help process the mapping is I 
think a good practical idea.

But could we do this in a more structured way to support the automated 
processing by tools that implement (i.e. generate and consume) the 
mapping in ITS?

For example we could offer best practice to reference with a URL 
identifying the type of the non-ITS QA issue, MQM specifically in this 
case. We could manage this via identifiers of the mapping via URLs at 
the ITS IG wiki, e.g.:

http://www.w3.org/International/its/wiki/LQItoMQM#terminology-Accuracy.Terminology  <http://www.w3.org/International/its/wiki/Localization_quality_types_mappings>

I've put an example page up (we could have similar ones for other mapping).

We would need then to specify best practice in how to reference this 
from some LQI annotation. Possibilities I could think of were:

1) Reference the type level mapping URL from locQualityIssueProfileRef

e.g. <span its:locQualityIssueType="terminology"
                   its:locQualityIssueComment="bad term"
                   its:locQualityIssueProfileRef=
"http://www.w3.org/International/its/wiki/LQItoMQM#terminologyAccuracy.Terminology">blah</span>

pros: a (sort of) natural use of locQualityIssueProfileRef
cons: the dereference document (in this case a fragment) would need to 
include a reference to the actual QA model, ie. MQM - though that makes 
sense anyway. Arle this would need MQM document fragment URLs for each 
type, again a good diea anyway.

2) reference the mapping page from locQualityIssueProfileRef and use a 
prefix to the value of  locQualityIssueComment with a space separating 
the start of any actual comment text.

e.g. <span its:locQualityIssueType="terminology"
its:locQualityIssueComment="terminologyAccuracy.Terminology bad term"
                   its:locQualityIssueProfileRef=
"http://www.w3.org/International/its/wiki/LQItoMQM#">blah</span>

cons: need some intelligence to parse comment to understand it contains 
a mapping reference

3) put the whole URL to the type mapping as a prefix of the value of 
locQualityIssueComment

e.g. <span its:locQualityIssueType="terminology"
its:locQualityIssueComment="http://www.w3.org/International/its/wiki/LQItoMQM#terminologyAccuracy.Terminology 
bad term"

pros: doesn't require use of locQualityIssueProfileRef, which may anyway 
be superfluous if only one profile used in the document, or allows the 
MQM doc to be ferferenced directly. Also the parsing of the reference 
from the comment is a bit more straightforward, though the processor 
still needs to be 'mapping aware'

So my own preference amongst these would be for (3), but there may be 
other better ways to do this.

any thoughts?
cheers,
Dave