Re: [all] readiness and translation process parameters

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

cheers,
Dave



On 04/07/2012 05:56, Felix Sasaki wrote:
> Hi David,
>
> 2012/7/4 Dave Lewis <dave.lewis@cs.tcd.ie <mailto: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
>