[Index] [Process] [All issues] [In work issues] [Open NoRes issues]
Export date: 2012-11-02 06:32:16
Row | Id | Category | Summary | Details | Priority | Status | Resolution | Release | Submitter | Assignee | Closer | Date raised | Date Closed |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | 3581906![]() |
Add Catalog ref data | Add the reference data required for the catalog templates http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#CatalogItemRealization http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#CatalogItemStructure http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#CatalogItem http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Catalog | 5 | Open | Remind | robbod | nobody | nobody | 2012-10-30 01:19:05 | 1970-01-01 12:00:00 | ||
2 | 3581916![]() |
Add ResourceOrder ref data | Add the ref data required by the resource templates http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Resource_order (subclass of WorkOrder) http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Resource_order_acknowledgment (subclass of WorkOrder) http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#DirectedActivity_planned_delivery (subclass of DirectedActivity) http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#ActivityActual_delivery (subclass of ActivityActual) http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Receipt (subclass of Approval) | 5 | Open | Remind | robbod | nobody | nobody | 2012-10-30 01:55:35 | 1970-01-01 12:00:00 | ||
3 | 3582131![]() |
corrrect and complete owl classes: Effectivity | The hierarchy of owl classes under Effectivity need to be reviewed and corrected | 5 | Open | Remind | robbod | nobody | nobody | 2012-10-31 07:11:39 | 1970-01-01 12:00:00 | ||
4 | 3582242![]() |
Actual_effectivity : Wrong subClassOf | http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Actual_effectivity is currently defined as a subClassOf "StateAssignment" it should be a subClassOf EffectivityAssignment. | 5 | Open | Remind | phoubaux | nobody | nobody | 2012-10-31 02:51:52 | 1970-01-01 12:00:00 | ||
5 | 3581920![]() |
corrrect and complete owl classes under Name | The hierarchy of owl classes under name reflects the Block type to which a name can be assigned. E.g. Assembly_component_name Breakdown_element_name etc This is not necessary - as, unlike an identifier, a name should not have any rules governing its structure, a simple name class should be sufficient. Any further classification of name should be down in context specific reference data Keep name and remove all sub classes | 5 | Pending | Remind | robbod | nobody | robbod | 2012-10-30 02:06:33 | 2012-11-01 04:38:17 | ||
1 | 3572714![]() |
the set of owl classes for id codes should be complete | 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. For example InformationUsageRight has an attribute called "id" 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 exist in the OWL plcs-rdl-en.owl file under the Identifier class. In this case the relevant name for the class would be "Information_usage_right_identification_code" (or similar - the exact naming convention is something that requires a separate discussion). | 5 | Pending | Accepted | mikeward | mikeward | robbod | 2012-09-28 10:35:48 | 2012-11-01 04:40:25 | ||
2 | 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 | Pending | Accepted | mikeward | mikeward | robbod | 2012-09-28 10:44:41 | 2012-11-01 04:47:28 | ||
3 | 3581920![]() |
corrrect and complete owl classes under Name | The hierarchy of owl classes under name reflects the Block type to which a name can be assigned. E.g. Assembly_component_name Breakdown_element_name etc This is not necessary - as, unlike an identifier, a name should not have any rules governing its structure, a simple name class should be sufficient. Any further classification of name should be down in context specific reference data Keep name and remove all sub classes | 5 | Pending | Remind | robbod | nobody | robbod | 2012-10-30 02:06:33 | 2012-11-01 04:38:17 | ||
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 | Pending | Accepted | mikeward | mikeward | robbod | 2012-10-11 07:19:54 | 2012-11-01 01:12:09 |