Tracker: PLCS Ref. data  :—Issues for CCB decision

[Index] [Process] [All issues] [In work issues] [Open NoRes issues]

Export date: 2012-10-15 09:46:35

Row Id Category Summary Details Priority Status Resolution Release Submitter Assignee Closer
1 3572716 owl classes for id codes should be consistently named Every SysML block that can be assigned an identifier should have a corresponding owl class that is a sub-class of "Identifier" and that can be used to classify the relevant Identifier and the name of that class should be derived directly from the name of the original block. For example GlobalLocationRepresentation has an attribute called "id" (inherited from LocationRepresentation) which allows for the assignment of one or many Identifiers. Each Identifier can in turn be assigned a Classification that may be an Owl class (or some other type of class). If an Owl class is to be used, it should be called "Global_location_representation_identification_code" (or similar - the "identification_code" suffix is something that requires a separate discussion). It is currently called "Geographic_location_identification_code" - something that cannot be reliably inferred from the relevant block. 5 Open Remind mikeward nobody nobody
2 3572722 owl classes for id codes should be consistently structured Every SysML block that can be assigned an identifier should have a corresponding owl class that is a sub-class of "Identifier" and that owl class should appear in a hierarchy that is structured just like the main class tree. For example the owl class "ActivityMethod" has (inter alia) a sub-class called "TaskElement" and "TaskElement" has (inter alia) sub-classes called "EndTask" and "ExitLoop": Activity_method Task_element End_task Exit_loop All the corresponding SysML blcoks can be assigned identifiers which can in turn be assigned a Classification that may be an Owl class (or some other type of class). The relevant Owl classes should be as follows: Identifier Activity_method_identification_code Task_element_identification_code End_task_identification_code Exit_loop_identification_code This hierarchy reflects that the set of exit loop ids is a subset of the set of task element ids which is (in turn) a subset of the set of activity method ids and also provides a reliable way to infer the route to a particular owl id class in the tree. (The "identification_code" suffix is something that requires a separate discussion) It can be argued that other groupings are required - eg the set of owl id classes that include the word "version" (not all of which will occur under "Product_version_identification code") but if this is felt necessary, an additional class called "Version_identification_classes" (or similar) should be created and all the relevant owl classes should be included in that class IN ADDITION to their inclusion in the "correct parent class in the owl tree. Such additional groupings would provide an additional navigation mechanism, but at the expense of additional complexity. 5 Open Remind mikeward nobody nobody
3 3576600 corrrect and complete owl classes under ExternalUnit we should create the following class tree: Non_si_unit Context_dependent_unit Us_imperial_unit Si_unit Derived_si_unit_or_multiple Named_derived_si_unit_or_multiple Unamed_derived_si_unit__or_multiple Si_base_unit_or_multiple (though we might use different names) We should then create instances under these classes as follows: Non_si_unit Context_dependent_unit: A small set of examples (eg Flying_hours) according to the needs of the Templates Us_imperial_unit: One or two examples (eg Pound Foot) Si_unit Derived_si_unit_or_multiple Named_derived_si_unit_or_multiple: The complete set of named derived SI units (eg newton pascal) and a small set of multiples (eg kilonewton micropascal) Unamed_derived_si_unit_or_multiple: A small set of examples (eg square_metre square_kilometre) Si_base_unit_or_multiple The complete set of base SI units (eg metre ampere kilogram) and a small set of multiples (eg kilometre microampere gram) The assumption being that these sets of units would be extended as the need arises 5 Open Remind mikeward nobody nobody
4 3576418 quality of content corrrect and complete owl classes under DateTimeAssignment the current hierarchy of owl rdl classes under the DateTimeAssignment classes is partially constructed according to a date-role facet: planed/actual, start/end ect, but also includes classes based (at least partially) on the target of the assignment: Date_actual_approval, Work_order_issue_date etc. If assignment target classes are to be created then we should require a complete set: Date_assignment_to_activity [....] Date_assignment_to_product Date_assignment_to_part Date_assignment_to_product_concept [....] Date_assignment_to_project and so on Each class would have to be further specialized as Planned_start_date_assigned_to_activity, Actual_end_date_assigned_to_activity, Planned_end_date_assigned_to_activity [....] Planned_start_date_assigned_to_project and so on This would result in a non-trivial number of RDL classes which would be difficult to navigate. Multiple classification using multiple facets such as Activity/Project, Planned/Actual, Start/End would avoid this problem, but that approach has been rejected - partly because of the implications for file-size. Given these considerations, the only realistic coherent solution is to have a single tree along these lines: DateTimeAssignment Actual_date_assignment Actual_start_date_assignment Actual_end_date_assignment [....] Planned_date_assignment Planned_start_date_assignment Planned_end_date_assignment etc (though we could re-use the existing names for these classes) and to delete all the classes based on assignment targets, specifically: Date_actual_approval, Date_actual_certification, Date_actual_observation, Date_message_data_frozen, Date_message_sent, Work_order_issue_date, Work_request_issue_date, Work_order_required_completion_date. This would imply the creation of some additional general classes such as: Actual_completion_date_assignment, Planned_sending_date_assignment etc The documentation for such classes should be used to indicated what the relevant (or typical) assignment targets are: Thus a start_date might apply to an activity or a project but not to a part. A sending date might apply to a message but not to a risk-event - and so on 5 Open Remind mikeward nobody nobody