Re: LocQualityProfileRef target

+1 for a dedicated wiki section

This would be great to better follow and contribute to the discussion 
instead of browsing through various email threads.

Cheers -- Jörg

On July 04, 2013 at 19:11 (CEST), Felix Sasaki wrote:
> Hi Arle, all,
>
> thanks a lot for this thread and pushing this discussion. Again I am
> only wondering whether we should gather this in the wiki  in a dedicated
> ITS2 <> MQM page. We have already touched so many points (mapping of
> types, MQM serialization options and how they relate to ITS2, role of
> profileRef, ...) so that it may be hard to remember the various options.
>
> Best,
>
> Felix
>
> Am 03.07.13 12:45, schrieb Arle Lommel:
>> Hi all,
>>
>> Just as a follow up to my last email, I thought I'd jot down some
>> issues since I probably will not make it to the call today (I have an
>> off-site meeting). These are some issues to consider.
>>
>> *1. One- or two-file profiles?*
>> From the MQM perspective, we want to have a master repository of
>> information on issue types that includes extensive metadata, such as
>> examples, notes, and translations of names into multiple languages.
>> Such a repository will be required if implementers are to have
>> guidance on how to implement categories (going beyond bare labels).
>> Such a repository would have quite a bit of metadata about each
>> category, including at least the following:
>>
>>   * Full name(s) for the category (as distinct from the token name),
>>     possibly in multiple languages. (We want to support users who are
>>     not working in English.)
>>   * Explanations of the category (again, possibly in multiple languages)
>>   * Usage notes to guide users in how to apply categories (along the
>>     lines of the notes in the ITS 2.0 table of issue types)
>>
>>
>> The issue is that once we start putting all this metadata in and want
>> to ensure that it is kept up to date, it is bad data management
>> practice to start stuffing it into every metrics declaration file. The
>> metrics declaration file (= the target of the profileRef) should be as
>> simple and straight-forward as possible.
>>
>> So I'm wondering if we need to take a TBX approach in which there is a
>> master repository with all the metadata and then the actual metrics
>> declaration just refers to the issue types from that repository, but
>> doesn't include all this metadata.
>>
>> The pro for this is that it makes for much cleaner data management and
>> a simpler way to declare a metric (I'm guessing we'd see an 80-90%
>> reduction in verbosity in the metrics declarations). The declaration
>> would need to invoke the particular master repository it is using (I'd
>> envision keeping an archived of numbered versions), but once that is
>> done, it could be very simple. If you want to exchange metrics, you
>> send a simple file around, not the full (and bloated) declaration.
>>
>> The drawback is that you then need two files if you want all the
>> metadata so the developer cannot simply load a single file. In
>> addition, because you need two files, single-step parsing and
>> validation of metrics data embedded in a document is harder since
>> there is no single schema that contains all the constraints about what
>> you need in it. This is the same issue TBX faces with the DTD+XCS file
>> construct and there are those who don't like it. In principle,
>> however, if we don't insist on a single specific location, a tool
>> developer could cache that master declaration locally and use it
>> locally, taking out some of the pain of a two-file approach.
>>
>> My own inclination is to take a two file approach. It is the only way
>> I can see to preserve integrity in MQM over the long haul.
>>
>> I'm not sure if my argument here is clear or not (I'm assuming a lot
>> of background knowledge) and if it isn't, I'll try to explain it in
>> our next ITS interest group call.
>>
>> *2. A generic mechanism?*
>> This topic has already emerged, but the question is whether we want to
>> develop a generic mechanism to describe a profile ref or if I should
>> just focus on an MQM-specific mechanism. I would be inclined to
>> develop more generic mechanisms (keeping MQM in mind, obviously),
>> possibly feeding into a companion W3C recommendation in the future so
>> that there is a structure to the profileRef that a future version of
>> ITS 2.0 could mandate :-)
>>
>> I would also then want to give ITS 2.0 a privileged place in this
>> mechanism by mandating that a profileRef contain a mapping to ITS 2.0
>> categories so that the connection is made transparent. (The issue of
>> one- vs. two-file solutions addressed above impacts this to some
>> extent, since in a two-file solution, the mapping would be in the
>> master declaration as metadata, but the actual metric declaration file
>> would not contain this.)
>>
>> If we go with a generic mechanism, I would then use it for defining
>> MQM formally, helping unify these approaches.
>>
>>
>>
>> I'm sure there are other issues, but I'm hoping that the files I sent
>> yesterday and some of this discussion will spark enough
>> interest/discussion that I will know that there is real interest out
>> there in tackling some of these issues.
>>
>> Best,
>>
>> Arle

Received on Friday, 5 July 2013 08:20:42 UTC