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

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 
> <mailto: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 orrevision state, since these can be values 
>>> ofprocess 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.
>>>
>>