Re: [all] Discussion on proposed metadata categories: approvalStatus

Hi Phil,

On 26/04/2012 07:18, Phil Ritchie wrote:
> I have some thoughts on this but won't get to articulate them until 
> tomorrow (over worked).
>
> In general LSP's would be used to getting content ahead of final 
> publication and then incrementing revisions up until publication date. 
> Note the process that we had for our own press release!
>
> I'm not sure dictating a start date to an LSP is beneficial. Each 
> sub-process should surely be a black box.

I agree, the semantics of 'ready-at' should not dictate the start time 
of the process. The intention is that it merely indicates the point at 
which the content is *ready* to be submitted to the process specified in 
'requested-process'.  If would be down to the service provider to manage 
the internal scheduling of the work. The constraint applied should be 
the 'completed-by' - but that standard practice I guess.

If its a time stamp that already past, it indicates that the content is 
ready. I imagined this might be more useful than just a 'yes/no' ready 
flag, since the process providers (typically the LSP) knows how much of 
their lead time has passed.

If its a time in the future, it gives an estimate of when the content 
will be ready, again this may be useful for enabling LSPs to plan their 
work schedule.

>
> Therefore less granular categories and perhaps more values might be 
> the way to go. More later.
>

Yes, this is a key issue. Again this data category only specified the 
_next_  process as visible via the document held in a CMS or a staging 
cache. If the process involves a number of steps before being returned 
to the CMS/cache (e.g. by being passed around various tools using 
XLIFF), I imagined this is opaque, and just treated as a single process 
in the 'requested-process' category.

Whether we then need to define the process steps within the process is 
an interesting issue. Maybe the client doesn't care, but if they will 
want visibility into execution history and quality of the steps via the 
proveance data category, then some way of defining a composite process, 
i.e some flow of process sub steps, would be needed. I'm not clear on 
what depth of detail is needed here though - would just a sequence of 
steps suffice?

talk to you later,
Dave


> Phil
> Twitter: philinthecloud
> Skype: philviathecloud
>
>
> On 26 Apr 2012, at 00:53, "David Lewis" <dave.lewis@cs.tcd.ie 
> <mailto:dave.lewis@cs.tcd.ie>> wrote:
>
>> 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.
>>>
>>
>
> ************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the sender immediately by e-mail.
>
> www.vistatec.com
> ************************************************************
>