Re: [all] readiness and translation process parameters

2012/7/4 Dave Lewis <dave.lewis@cs.tcd.ie>

>  Felix,
> The consensus at the Dublin meeting was that the data model already
> documented in the requirement doc was broadly OK, it was just the
> additional attributes that needed to be addressed, hence this post to
> address this. We already had 6 implementation proposals for readiness based
> on this status so there's interest indicated, see:
> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#Implementation_Proposals
>
> So for readiness, I'm making the point that logically I don't think the
> additional attribute really fit, and give a _concrete_ suggestion to
> illustrate where they might be better placed that people can react to and
> therefore draw the readiness issue to a close as quick as possible.
>
> I'm not particularly championing this new transParam data category, just
> pointing out this might be a way to address some of these similar issue
> that people have expressed in various places (perhaps call it special
> requirements - good idea, it could include postediting), again hopefully
> drawing those to a close quickly. This transParam proposal obviously punt
> the agreement on type and value to best practice, which mean we could
> perhaps resolve the issues more quickly, but the question is does this
> render the proposal too soft on interoperability to be useful?
>
> Really these are questions for WG members representing LSP and their
> clients who have to deal with these parameters in their relationships,
> Pedro, Milan, Des, Jan etc
>

Yes, I totally agree - and we need input from several of these parties
about this.

Felix


>
> cheers,
> Dave
>
>
>
>
> On 04/07/2012 05:56, Felix Sasaki wrote:
>
> Hi David,
>
> 2012/7/4 Dave Lewis <dave.lewis@cs.tcd.ie>
>
>>  Hi all,
>> Prior to attempting a call for consensus on the readiness data category I
>> wanted to address some of the outstanding issues listed at:
>>
>> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#readiness
>>
>
>  Readiness is not yet on the list at
>
> http://www.w3.org/International/multilingualweb/lt/wiki/Implementation_Commitments
> and we are far from a call for consensus AFAIK.
>
>
>
>>
>>
>> These were touched on by Pedro in Dublin and merited further discussion.
>>
>> I will address each separately in another post
>>
>
>  I would hope that we will concentrate on filing the empty cells at
>
> http://www.w3.org/International/multilingualweb/lt/wiki/Implementation_Commitments
> within the next three weeks - that is already a challenge, given other,
> non MLW-LT work items. It would be a shame if we don't have provenance and
> quality related data categories, but a set of new proposals ;)
>
>
>
>> , but my primary observation is that many relate to instruction
>> specifically for translation to be carried out on the whole document. This
>> is consistent with the overlap with ISO/TS 11669 observed in comments .
>> Taking the ISO/TS 11669 related summary at: http://www.ttt.org/specs/
>> these are essentially parameters to a translation job specification, but
>> also work in progress and perhaps something that will be difficult to align
>> with normatively in our timeframe (arle?).
>>
>> Therefore, I propose we do not include such translation job parameters in
>> readiness because:
>>
>> 1) readiness is use to signal the point in time when some content is
>> ready to be processed by a named process. It is agnostic to what that
>> process is, it could be e.g. named-entity-recognition. So including
>> _translation_ process specific parameters is a scope mismatch and therefore
>> overloads the intended semantics of the readiness data category.
>>
>> 2)  Translation process parameters may be more appropriate as separate
>> data categories as they are more generally useful even when readiness is
>> _not_ used.
>>
>> This implies a new data cateogry for translation parameters. I don't see
>> many use cases for applying these at the local level (but please shout if
>> you see them). Therefore we could propose a global data category transParam
>> element that contains:
>>
>
>  I see an overlap between translation parameters and specialRequirements
> - the user probably will ask "how do they relate to each other"?
>
>
>>
>> A) a selector indicating part of the document to which the translation
>> parameters apply  (often but not always"/html/body")
>>
>> B) a required transParamType
>>
>> C) a required transParamValue
>>
>> Where transParamType and transParamValue are given non-normative best
>> practice definitions, ideally then aligned with ISO/TS 11669 as it matures.
>> e.g.
>>
>> <its:rules
>>   xmlns:its="http://www.w3.org/2005/11/its" <http://www.w3.org/2005/11/its>  version="2.0">
>>  <its:transParam selector="/html/body" transParamType="*contentResultSource*" transParamValue="yes"/>
>>  <its:transParam selector="/html/body/diclaimer" transParamType="*pivotLang*" transParamValue="en"/>
>> </its:rules>
>>
>>
>> The class of potential translation process parameters data categories
>> could include:
>>
>> a) sourceLang, contentResultSource, contentResultTarget, pivotLanguage
>> from the readiness comments
>>
>> b) the remaining  project related data categories ;
>>
>> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#Project_Information
>>
>> c) the post-editing parameters suggested in:
>>
>> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jun/0050.html
>>
>
>  I would disagree with this approach on two levels: first, if we don't
> have two implementations making use of a) b) c), there is no value in
> trying to push for them. Second, we run into the same issue as with
> specialParameters. As Pedro pointed out at
>
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jul/0001.html
> we need people who solve the detailed issues to move this forward.
>
>  It's OK *not* to do many things mentioned in the requirements document.
> We can also do ITS 3.0 at some point :) For now, we should concentrate on a
> few topics and do them well.
>
>  Felix
>
>
>>
>>
>> cheers,
>> Dave
>>
>>
>
>
>  --
> Felix Sasaki
> DFKI / W3C Fellow
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow