AW: [ACTION-79]Consider consolidation of status-related data categories and process trigger

Hello Dave,

 

thanks for adding it. 

 

Moritz, does this distinction match with your view here? If so then we could
introduce a new 'progress-indicator' data category requirement, and then
continue discussing the consolidation of 'process state' with
processTrigger/readiness.



Yes.

 

Cheers,

Moritz

 

Von: David Lewis [mailto:dave.lewis@cs.tcd.ie] 
Gesendet: Freitag, 4. Mai 2012 02:46
An: public-multilingualweb-lt@w3.org
Betreff: Re: [ACTION-79]Consider consolidation of status-related data
categories and process trigger

 

Hi Moritz, guys,
I added this progress-indicator data category to the requirements:
http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#progress

-indicator

Regards,
Dave

On 28/04/2012 22:11, David Lewis wrote: 

Hi Morwitz,
I moved this onto this separate thread related to the relevant consolidation
action.

I think there are two different data categories here.

What you describe is a progress indicator. This would be a common feature on
a lot of CMS-based and crowdsourced translation tools. It would be measured
as the number of segments (or perhaps words) of a document (or a group of
document representing a job) that have been processes as a proportion of the
total that need to be processed.

The other, which is what the current text for 'process state'
(http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#process

_state) specifies, is an indication of  which point in a process sequence has
currently been reached. As discussed, this could be covered by the
processTrigger/readiness data category we are discussing.

Moritz, does this distinction match with your view here? If so then we could
introduce a new 'progress-indicator' data category requirement, and then
continue discussing the consolidation of 'process state' with
processTrigger/readiness.

thanks,
Dave


On 27/04/2012 18:40, Moritz Hellwig wrote: 

Hello,

 

I might make this a separate thread, but since we are already talking about
processState here...

 

There were quite a lot of requests from our editorial team to have something
like

 

processIndicator 

Values integer, 0 to 100

 

Zero would be "LSP process not begun"-ish, 100 would be "Completed". 

 

There are - from our point of view - considerable advantages:

A) we can show a process progress indicator (in whichever visual
representation) that does not require an understanding of what the actual
process phase is on the MT side. 

B) the indicator can be agnostic to the number of processes / stages on the
side of the LSP. If you run a hundred separate processes or feedback loops:
fine by me.

 

This would be beneficial for e.g. content creators who are unfamiliar with
the language technology, its processes and so on. Also, it would allow us to
built dashboards and generate reports e.g. to show and sort by progression &
keep better track of multilingual projects. 

 

Any thoughts?

 

Cheers,

Moritz

Sent from my iPhone


On 27.04.2012, at 01:14, "David Lewis" <dave.lewis@cs.tcd.ie> wrote:

 Pedro,
 Yes, the redundancy of process state is one outcome of what I'm
proposing here.
 
 The key difference is that the proposal is that the data category
indicates the next process that should be performed, rather than indicating
the current process in operation. The motivation is that the readiness to
undergo a new process step is more useful to a document in a CMS, then
knowing the current state that is operating on it.
 
 Complementary to this, provenance indicates that a process is
completed, and associated with this records useful information needed to
monitor correct or efficient process operation, perhaps as needed to monitor
a service level agreement.
 
 Neither process trigger or provenance however actually aim to control
process flow. This is a complex topic which therefore is probably out of
scope. 
 
 What we do need however, is a way of defining  the values to use for
referencing processes, i.e. from both the 'request-process' and the process
reference in provenance. For this we may want both a default set in the
standard, and a way of unambiguously defining these for a particular business
case. The key thing in any one case of interoperability is that the
interoperating implementations exchange and understand the _same set_ of
process values. 
 
 let keep the discussion going on the list,
 Dave
 
 On 26/04/2012 15:29, Pedro L. Díez Orzas wrote: 

 Hi David,

  

 I need to consider this more carefully. 

  

 But, what I see is that process state is perhaps redundant with:
proofreading state or revision state, since these can be values of process
state: proofreaded, revised, reviewed, translated, localized…

  

 Best,

 Pedro

  

 
________________________________


 De: David Lewis [mailto:dave.lewis@cs.tcd.ie] 
 Enviado el: jueves, 26 de abril de 2012 1:52
 Para: public-multilingualweb-lt@w3.org
 Asunto: Re: [all] Discussion on proposed metadata categories:
approvalStatus

  

 Hi Moritz,
 I think you make a very good general point here. It may be a bit too
open ended to specify data categories that hardwire the completion of a
specific step. We would run into the same issues we have with defining the
different process values as we discussed around process trigger. Also, its
not clear to me that all status flag suggestion for current steps, e.g. legal
approval, really need to be separated from other steps.
 
 I think therefore we could generalise this as part of the process
trigger data category as you suggest. This could allow us to consolidate
approvalStatus, cacheStatus, legalStaus, proofReading state and revision
state (and delegate the definition of these steps to data values rather than
individual data categories). We can address cacheStatus, and at he same time
generalise it to other processes than just translation, by including the time
stamp and a revision flag. 
 
 Also, I think the priority data category should be included here, as
translation could consist of many different processes in combination, so it
semantics are dependent on which one. At the same time we may also be
interested in defining priorities even for non translation activities, such
as review.
 
 requested-process (which has the name of the next process requested)
 
 process-ref (which may allow us to point to an external set of
process definitions used for processRequested if the default value set is not
used)
 
 ready-at (defines the time the content is ready for the process, it
could be some time in the past, or some time in the future - this support
part of the cacheStatus function)
 
 revised (yes/no - indicated is this is a different version of content
that was previously marked as ready for the declared process)
 
 priority (I think for now we should keep this simple and just have
values high/low )
 
 complete-by (provides a target date-time for completing the process)
 
 Any thoughts on this suggestion. Pedro, Ryan, Moritz, Des, I think
this impacts on data categories you have an interest in.
 
 Also, DavidF, Pedro, Ryan, do you think this makes process state
redundant? As a status flag are we more interested in what process to do
next, rather than which one is finished. At the same time the provenance data
category could tell us which processes have already finished operating on the
content. 
 
 cheers,
 Dave
 
 
 On 24/04/2012 11:11, Moritz Hellwig wrote: 

 to identify publication process metadata which might also be relevant
for the LSP. I ran into a couple of questions though.

  

 I’ll use approvalStatus as an example (from the requirements
document):

 >> approvalStatus 

 >> Information about the status of the content in a formal approval
workflow

 >> Indicates whether the content has been approved for release 

 >> Possible values:

 >>>> yes

 >>>> no

  

 Approval can have many values which are rarely only “release yes|no”
and they can be client/application-specific. However, none of these statuses
seem to be relevant to the LSP, as they only precede or succeed the LSP’s
processes.