Issue raised against reference data plcs_owl


Open issue Issue: RBN-2 by Rob Bodington (04-07-19)
Class: Task_category (plcs-rdl-sdk.owl)
Category: minor_technical
Resolution: Accept. Status: open

Create the Maintenance_task_descriptive_categories and make all the TRILS task_categories and TRILS procedure_categories sub classes of Maintenance_task_descriptive_categories. Then make ILS_descriptive_categories a subclass of Activity_method - but check the TRILS to PLCS mapping The definition: A categorization of maintenance tasks according to the description of the task for the maintainer.


Open issue Issue: RBN-5 by Rob Bodington (04-08-17)
Class: Information_representation (plcs-existing.owl)
Category: editorial
Resolution: Accept. Status: open

Source is PLCS derived from ISO 15926 class "class_of_representation_of_thing"


Open issue Issue: RBN-18 by Rob Bodington (05-01-12)
Class: ()
Category: minor_technical
Resolution: Accept. Status: open

Renamed Person_in_organization_code to Person_in_organization_identification_code


Open issue Issue: RBN-19 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Renamed Employee_identifier to Employee_identification_code


Open issue Issue: RBN-20 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Created Product_as_individual_identification_code and made it a super class of Serial_identification_code.


Open issue Issue: RBN-21 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Made Project_identification_code a sub class of Individual_identification_code rather than Activity_identification_code as a project may be an activity or maybe an organization.


Open issue Issue: RBN-22 by Rob Bodington (05-01-12)
Class: Breakdown_element_identification_code (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Deleted sub classes of Breakdown_element_identification_code: LCN_identification_code and SNS_code as they should be put into the ref data for the AECMA.


Open issue Issue: RBN-23 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

renamed Organization_assigned_code to Organization_identification_code to be consistent with the naming of the supertype as identification_code


Open issue Issue: RBN-24 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

renamed Part_type_code to Part_identification_code to be consistent with the naming of the supertype as identification_code


Open issue Issue: RBN-25 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

renamed Progression_code to Progression_identification_code to be consistent with the naming of the supertype as identification_code


Open issue Issue: RBN-26 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Made Part_identification_code a sub class of identification_code


Open issue Issue: RBN-27 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Add the following as subclasses of identification_code Activity_method_identification_code Attachment_slot_identification_code Breakdown_identification_code Breakdown_element_identification_code Certification_identification_code Contract_identification_code Document_identification_code File_identification_code Qualification_type_identification_code Requirement_identification_code Resource_item_identification_code Scheme_identification_code State_definition_identification_code Task_identification_code Type_of_person_identification_code State_identification_code Resource_event_identification_code Product_group_identification_code Location_identification_code


Open issue Issue: RBN-28 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

In defining the reference data for the id_assignment we would like to establish a constraint between what is being identified and between what is being classified. I.e. not allow a person to have a part number id assigned. To this end a set of subclasses have been created that reflect the entity that is being identified. E.g. person_identiifcation_code, is a subclass of indentification_assignmement that identifies a person. Identification_assignment has subclasses Individual_identification_code, Type_identification_code that distinguish between the type and individual. By creating sub classes that reflect the entity that is being identified we have in fact made the distinction between type and individual. We see no reason why we should have the sub classes Individual_identification_code, Type_identification_code. In fact there are some entities for which it is not clear as to whether they are a type or individual. For example, an activity_method used to hold the description of a regulation. Therefore should delete Individual_identification_code, and Type_identification_code For the same reasons, we have deleted: Individual_name and type_name and made Part_type_name a subclass of Name.


Open issue Issue: RBN-29 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

renamed Configuration_code to Product_configuration_identification_code


Open issue Issue: RBN-30 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Renamed Product_concept_code to Product_concept_identification_code


Open issue Issue: RBN-31 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Deleted Activity_type_identification as this is now replaced with Activity_method Activity_type_identification


Open issue Issue: RBN-32 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Renamed Part_type_name to Part_name


Open issue Issue: RBN-33 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Deleted Date_created and created Date_actual_created and Date_planned_created


Open issue Issue: RBN-34 by Rob Bodington (05-01-12)
Class: (plcs-rbn-rdl.owl)
Category: minor_technical
Resolution: Accept. Status: open

Changed Concession to be a subclass of Approval rather than Approval_assignment.


Open issue Issue: RBN-35 by Rob Bodington (05-01-12)
Class: (plcs-rbn-mwd.owl)
Category: minor_technical
Resolution: Accept. Status: open

Delete Approval_purpose, Approval_assignment_role, Approver_role class as it is just a place holder Delete Approval_relationship_type class and make the subclasses a class of Approval_relationship.


Open issue Issue: RBN-36 by Rob Bodington (05-01-12)
Class: plcs-rbn-rbn.owl ()
Category: minor_technical
Resolution: Accept. Status: open

Delete the class concessed (a sub class of Approval status) - this is redundant as we have a classified Approval - concession.


Open issue Issue: RBN-37 by Rob Bodington (05-01-12)
Class: (plcs-rdl-mwd.owl)
Category: minor_technical
Resolution: Accept. Status: open

rename the sub classes of Approval_relationship_type by removing the _relationship suffix. Then delete the class Approval_relationship_type


Open issue Issue: RBN-38 by Rob Bodington (05-01-13)
Class: (plcs-rdl-rbn.owl)
Category: minor_technical
Resolution: Accept. Status: open

Created Part_category - a sub class of Part. This is to be used instead of the product_category entity. This should also be a sub class of Product_as_individual. Created categories for all


Open issue Issue: RBN-39 by Rob Bodington (05-01-13)
Class: ()
Category: minor_technical
Resolution: Accept. Status: open

Remove failure_mode classification of state_observed. The classification of a state is about how the observation that something in the state was made. The definition of the state that something is observed to be in is made by the state_definition. The state_observed, refers to that state_definition. The definition of the state is then provided by a classification of the state_definition


Open issue Issue: RBN-40 by Rob Bodington (05-09-21)
Class: part_identification_code (plcs-proposed.owl)
Category: minor_technical
Resolution: Accept. Status: open

The sub classes of part_identification_code are XXX_type_codes - these should be renamed to identification_codes. E.g. Supplier_part_type_code, OEM_part_type_code, User_part_type_code, Supplier_part_identification_code, OEM_part_identification_code, User_part_identification_code,


Closed issue Issue: RBN-4 by Rob Bodington (04-07-19)
Class: Item_category (plcs-rdl-sdk.owl)
Category: minor_technical
Resolution: Accept. Status: closed

There is a mixture of identification codes and product categories that need to be separated.


Closed issue Issue: RBN-4 by Rob Bodington (04-07-19)
Class: Name_identification (plcs-existing.owl)
Category: minor_technical
Resolution: Accept. Status: closed

The definition does not enable a distinction between it sibling classes, a progression_code, a type code etc.
Comment: (Rob Bodington 04-09-02)
The definition has been improved: A Name_identification is an identification that is a string where the structure has no signifcance. For example, the name of a part. The name of a book.


Closed issue Issue: RBN-5 by Rob Bodington (04-08-17)
Class: Description (plcs-existing.owl)
Category: editorial
Resolution: Accept. Status: closed

This is a subclass of information_representation. The PLCS information model represents a description as an attribute on entities. In other words, there can only be one explicit descriptions. There is a requirement to record multiple descriptions for something and these descriptions have a context. I.e. the person or organization who provided the description. This class should be a sub class of string_property_assignment, document_assignment. Source is PLCS derived from ISO 15926 class "class_of_description"
Comment: (Rob Bodington 04-11-07)
Have created the class: Description as a subclass of document_Assignment


Closed issue Issue: RBN-5a by Rob Bodington (04-08-17)
Class: Identification_code (plcs-existing.owl)
Category: editorial
Resolution: Accept. Status: closed

Source is PLCS derived from ISO 15926 class "class_of_identification" The class should be renamed to identifier. The definition should be: An identifier is an information_representation that. The identification normally complies with a codification system resulting in an identification that is unique in a given context. The identifier class should have Name and Identification_code as sub classes. The identification_code should have a Type_identification_code, Individual_identification_code and progression codes as subclasses.
Comment: (Rob Bodington 04-09-02)
Better description provided and updated in plcs-rdl-rbn.owl


Closed issue Issue: RBN-6 by Rob Bodington (04-08-17)
Class: Configuration_code (plcs-existing.owl)
Category: editorial
Resolution: Accept. Status: closed

This needs a better description and clarification as to what it is that is being identified.
Comment: (Rob Bodington 04-09-02)
Better description provided and updated in plcs-rdl-rbn.owl


Closed issue Issue: RBN-7 by Rob Bodington (04-11-10)
Class: View_definition_context ()
Category: minor_technical
Resolution: Accept. Status: closed

The View_definition_context class should not have application_domain and life_cycle_stage. Instead the explicit intersection subclasses should be created.
Comment: (Rob Bodington 04-11-24)
At the DNV meeting we agreed that we do need the sub classes Application_domain and Life_cycle_domain subclasses to distinguish


Closed issue Issue: RBN-8 by Rob Bodington (04-11-10)
Class: View_definition_ ()
Category: minor_technical
Resolution: Accept. Status: closed

The Life_cycle_stages should reflect the sources of the life cyle definitions. Each different source should be stored in a separate OWL file with an explicit life_cycle_subclass. The class structure will be: View_definition_context Life_cycle_stage ISO_15288:Life_cycle_stage - these are the classes sourced from 15288 and still owned by ISO_15288:Concept_Stage ISO_15288:Production_Stage ISO_15288:Retirement_Stage ISO_15288:Support_Stage ISO_15288:Utilization_Stage ISO_10303_239:Life_cycle_stage - thes ISO_10303_239:Concept_Stage ISO_10303_239:Production_Stage ISO_10303_239:Retirement_Stage ISO_10303_239:Support_Stage ISO_10303_239:Utilization_Stage ISO_10303_214:Life_cycle_stage Design Manufacturing Recycling These are sourced from ISO 15288
Comment: (Rob Bodington 04-11-07)
I have created two new files: plcs-rdl-iso10303-214.owl plcs-rdl-iso15288.owl for representing the 15288 and 214 classes. I have updated the ont-policy file


Closed issue Issue: RBN-9 by Rob Bodington (04-11-10)
Class: Identification_assignment ()
Category: minor_technical
Resolution: Accept. Status: closed

The identification assignment entity represents two things. The identifier and the assignment of the identifier. The OWL identifier class represents the identifier. We need to add a new sub class: "assignment_type" This class will have subclasses: "deprecated", "preferred", "global" This class "Distinguish the use of a particular identifier in the context of alternative identifiers for the same item" The identifier class should be renamed identifier_type.
Comment: (Rob Bodington 04-11-07)
Added


Closed issue Issue: RBN-10 by Rob Bodington (04-11-10)
Class: Part_type_code ()
Category: minor_technical
Resolution: Accept. Status: closed

The Part_type_code should have sub classes OEM_part_type_code - an OEM part_type_code is the identifier assigned to a part by the Original equipment manufacturer. User_part_type_code - A User part_type_code is the identifier assigned to a part by the end user who has acquired the part and assigned their own identifier. Assembly_manufacturer_part_type_code - An assembly_manufacturer Part_type_code is the identifier assigned to a part by the manufacturer of an equipment in which the
Comment: (Rob Bodington 04-11-06)
Added


Closed issue Issue: RBN-10 by Rob Bodington (04-11-10)
Class: Name ()
Category: minor_technical
Resolution: Accept. Status: closed

The name structure should reflect the Identifier structure. The structure should be: name Individual_name Type_name Part_type_name Assembly_manufacturers_part_type_name OEM_part_type_name Supplier_part_type_name User_part_type_name
Comment: (Rob Bodington 04-11-07)
Added


Closed issue Issue: RBN-11 by Rob Bodington (04-11-24)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

Need to add the UNKNOWN class to the RDL - this explicitly states that something has not been classified.
Comment: (Rob Bodington 04-11-06)
Added UNKNOWN


Closed issue Issue: RBN-12 by Rob Bodington (04-11-24)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

The Application_domain class should have subclasses: Discipline_domain ISO_10303_239:Assembly_structure ISO_10303_239:Digital_mockup ISO_10303_239:Electrical_design ISO_10303_239:Mechanical_design ISO_10303_239:Process_planning ISO_10303_239:Product_life_cycle_support ISO_10303_239:Maintenance Process_domain ISO_10303_239:Agreement_processes ISO_10303_239:Enterprise_processes ISO_10303_239:Project_processes ISO_10303_239:Technical_processes
Comment: (Rob Bodington 2004-11-07)
Added - though have not separated the definitions into a separate file + ISO_10303_239 namespace as this does not make sense as the purpose is to define PLCS reference data.


Closed issue Issue: RBN-13 by Rob Bodington (04-11-24)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

Identification_code - employee_id. The employee id class only makes sense in the context of the person working in an organization. Therefore employee_id should be a sub class of person_in_organization_identifier
Comment: (Rob Bodington 04-11-02)
Created person_in_organization_code and subclass employee_id


Closed issue Issue: RBN-14 by Rob Bodington (04-11-24)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

Assigned_property This should have a sub class "properties". The properties class should be a sub class of "Assigned_property" "activity_property" "resource_property". This is to accommodate the fact that PLCS property entities have no common super type. All properties are then subclasses of "property". The properties has a subclass: Quantified_properties The Quantified property has String_property
Comment: (Rob Bodington 2004-11-06)
Added Quantified_properties and Qualified_property classes as described. It is not clear as to whether a string_property is now required.


Closed issue Issue: RBN-15 by Rob Bodington (04-11-09)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

The Serial_identification_code structure should reflect the Identifier structure. The structure should be: Serial_identification_code Assembly_manufacturers_serial_identification_code OEM_serial_identification_code Supplier_serial_identification_code User_serial_identification_code
Comment: (Rob Bodington 04-11-09)
Updated


Closed issue Issue: RBN-16 by Rob Bodington (04-11-09)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

The preferred identifier should indicate that the identifier is intended to be Globally unique.
Comment: (Rob Bodington 04-11-09)
Added text to description.


Closed issue Issue: RBN-17 by Rob Bodington (04-11-09)
Class: ()
Category: minor_technical
Resolution: Accept. Status: closed

The codification systems should be a sub class of CLASS. The actual codes should be stored as sub classes of the thing that is being classified. I,e, Task. In the case of product we can use product_category to carry the value (code) and classify the product_category. In the case of task etc this is not possible. There is no obvious entity that carries the value. The approach we have proposed is to use Class to carry the value, and then classify the class with the external_class where external_class provides the classification used for the code.
Comment: (Rob Bodington 04-11-09)
I have made Type_identification_code a sub class of the class entity.