Comments below.
Peter
-----Original Message-----
From: Barker, Sean
(UK)
[mailto:Sean.Barker@baesystems.com]
Sent: den 22 oktober 2007 12:22
To:
Trine.Hansen@dnv.com; Gyllström
Leif
Cc: plcs-dex@lists.oasis-open.org
Subject:
[plcs-dex] Representing Task
Following conversations with Leif, I am proposing to
develop the following template:
Representing_task_simple
The template is a cut down version of the
Representing_task capability. It will be limited to the usage phase of the
support solution, that is, it will not support the development of a task
description. It will do the following:
Instantiate Task_method and its identifier, name and
description
Instantiate Task_method_version with the task method
version identifier and classified as
"Task_status_in_use"
[pbm] I
would propose a default class as above, but enable other
classes to be used. Hard coded classes are a
pain.
SMB; OK
GYL: Is this classification really necessary
???
Optionally characterise a Task_method_version by
assigning a Product_concept or Product_version in the role of
"Product_in_focus", however I do not intend to make the link conditional on
effectivity
[pbm]
Please do not use the term "Product_in_focus" this way, it is
not what was meant in the PLCS standard, and
has been misinterpreted several times before.
Just avoid the term "Product_in_focus".
Suggestion: "Product_concerned"
SMB: OK - but
what is meant by Product-in-focus?
GYL: I would advocate the usage of Effectivity
(possibly Condition, depending on the conclusions from last weeks telecon with
Rob)
Instantiate a single Task_element and a single
description attribute in the role of
"Task_element_task_description"
[pbm] why
instantiate a task_element at all? I see no use for it, and it makes
things worse if somebody would like to extend this
task_method later on (by defining a
task_sequence or whatever). Put the
task_description at the task_method (or task_version?) using an
assigning_descriptor instead.
SMB: No
- this breaks the task model, and means that task_element information
could occur in two separate entities
GYL: I'm in favour of Seans suggestion, i.e.
that the Task_method_version does not carry information on how the task
is to be performed.
Optionally allow the Task_element to be characterized
by a document or partial document (which could be the maintenance manual) in
the role "Documented_task_description"
GYL: This could possibly be assigned to the
Task_method_version, since its probably a reference for the entire Task
?
I do not propose to include in the template the
following functionality discussed in the representing_task
capability:
- Task Objectives - to be a separate
template
[pbm] I
would propose to show that as a characterization
anyway
SMB: No. Scope
bloat.
GYL: I hope that you Sean will develop a template for
Tas_objective. !
- Task lifecycle and lifecycle
approval
[pbm] I would propose to show that as a characterization
anyway
- Task lifecycle relationships, including version
progression
- Task justification
[pbm] I would propose to show that as a characterization anyway
GYL: Is this to be represented by
Justification or Task_method_state_relationship ? Refereing to PBM
comment in another mail.
- meta information, such as owner, security
classification or copyright notice
[pbm] I would propose to show that as a characterization
anyway
- task properties such as cost and time
taken
- advisory task (such as safety
instructions
- resource allocation, including parts to be
fitted
- supporting
documentation
[pbm] are
you also planning templates in the near future for
t ask_properties, resource_allocation, and task
relationships? If not, I would prefer you showing those as
possible characterizations, so that we establish a "standard" for how that is
done.
SMB: Not near
future.
GYL: Properties are covered with existing
template for assigning_process_property
!
GYL:
Resource_allocation is covered by existing template
assigning_required_resource !
Note, this also excludes any functionality that would
have been covered by any of the other proposed capabilities, such as the
ability to identify environmental constraints.
GYL: This is covered
by assigning_state_definition (or something like that). Just an
additional
characterization.
Note this is a simple, one step task. There is a
proposal for a template for representing_task_sequence. It is not possible to
do this as a template, nor would it make sense to modify the syntax of
templates to make it possible.
GYL: We need to adress this ! How ?
Comments for 13:30 UK time,
please (Leif wants the template today)
Sean Barker
BAE SYSTEMS - Advanced Technology
Centre
Bristol, UK
+44(0) 117 302 8184
********************************************************************
This email and any attachments are confidential to the
intended
recipient and may also be privileged. If you are not
the intended
recipient please delete it from your system and notify
the sender.
You should not copy it or use it for any purpose nor
disclose or
distribute its contents to any other
person.
********************************************************************
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. You may a link to this
group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php