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

Pedro, guys,
I've renamed this thread to address a specific action on this consolidation.

On 27/04/2012 19:34, Pedro L. Díez Orzas wrote:
>
> Dave, I think it is clear to me:
>
> processTrigger provides the basic parameters to _activate_ a certain 
> localization process of the source content, while processState and 
> provenance indicate a certain _result_ (state or provenance) of the 
> target contents.
>

Yes, that a good characterisation. It raises the question of whether 
processTrigger and provenance should use the same processState names. 
This is a broader issues (actually [ISSUE-6]), and we should come back 
to that shortly.

> In this respect, the control could be done crossing info about the 
> "requested" (processTrigger) and the results (processState and 
> provenance), but this is already a functionality that belongs to the 
> CMS and I agree out of scope.
>

So in relation to 'processTrigger', all it is really saying is that the 
element concerned is ready (or will be ready at a specific time) for 
submission to a specified process. But while the data category is 
therefore necessary to trigger the process, it is not always sufficient 
to trigger the actual submission of the element to the process. Other 
issues, such as availability of translators, agreement of terms and 
conditions, higher priority jobs or exchange of payment, may all play a 
role in actually deciding when to start the processing of the element. 
But as we agree, the mechanism for making that decision, i.e. the actual 
process control, is out of scope.

I might then suggest, for the sake of clear and accurate communication, 
we change the name of the data category from 'processTrigger' to 
something like 'readiness'? Then instead of the suggested 
'requested-process', which sounds like a control request, we could 
rename this 'ready-for-process'

So in addition to the proposed attributes, perhaps we could state the 
requirement as something like:

"ITS2.0 should be able to indicate the readiness of an element for 
submission to different processes or provide an estimate of when and 
element will be ready for a particular process.

ITS2.0 should be able to indicate the relative priority elements should 
be subjected to when submitted to a process.

ITS2.0 should be able to indicate an expectation of when an a specific 
process should be completed for an element.

ITS2.0 should be able to specify if an element previously submitted to a 
process has subsequently been revised and therefore needs to be 
re-submitted to that process."

thoughts welcome.
cheers,
Dave

> Best,
>
> Pedro
>
> ------------------------------------------------------------------------
>
> *De:*David Lewis [mailto:dave.lewis@cs.tcd.ie]
> *Enviado el:* viernes, 27 de abril de 2012 1:13
> *Para:* "Pedro L. Díez Orzas"
> *CC:* public-multilingualweb-lt@w3.org
> *Asunto:* Re: [all] Discussion on proposed metadata categories: 
> approvalStatus
>
> 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 
> <mailto: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.
>