Issue raised against reference data plcs_owl
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.
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"
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
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
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.
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.
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.
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
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
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
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
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
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.
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
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
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
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
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
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.
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.
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.
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
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
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
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,
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.
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.
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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.
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.