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.
>