kbss-cvut / aircraft-maintenance-planning-system Goto Github PK

We have some data in CSV files where we get date and time separately.

1. • In some of the cases it happens that we have "end-date", but don't have concrete time (I guess user forgot to log in when he finished)
2. • In other cases we just don't collect so specific data, only day when it happened.

Thus, it seems valid to me to keep "date" and "time" separated using generic properties on events. We can infer specific properties of type xsd:dateTime or xsd:dateTimeStamp from that properties.

Thus i suggest to have new class cm:event, having:

cm:maintenance-task rdfs:subClassOf cm:event .

cm:event rdfs:subClassOf cm:start-date some (xsd:date)
cm:event rdfs:subClassOf cm:start-time some (xsd:time)
cm:event rdfs:subClassOf cm:end-date some (xsd:date)
cm:event rdfs:subClassOf cm:end-time some xsd:time)

Workpackage is create in AMOS where TCs and Scheduled work orders are specified. This issue should resolve the import of basic plan details from AMOS into the aircraft maintenance planning system.

Acceptance Criteria
The import solution should process the following data fields

• WP plan code
• Set of Task Cards included in the plan
• Set of scheduled work orders

Within csat-maintenance owl model "maintenance task type" and "maintenance task" have same URL cm:maintenance-task. This is inconsistent with conceptual model provided in graphml format.

Constraint should check that all columns of input CSV files are not changed, while omitting the order of columns.

Should be implemented in SPipes pipeline using SELECT+VALUES validation constraints from CSV schema description generated by Tabular module.

Blocked by: kbss-cvut/s-pipes#37

Update plan entity API - parent issue #38
create API to update each relation in the plan model
parent-child relation
relation to resource entities, e.g. mechanic, scope, aircraft, aircraft part,
create API to update basic properties of plan entities - for example, time frames, title, code, as well as other entities.

Within time-analysis and presence CSV transformation I have cm:presence and cm:work-session events that are spawning two days. I want to split those events into two subevents.

Model is defined in #21.

Goal is to prepare project for dockerization.

The service should use data from repository (this must be configurable):
https://graphdb.onto.fel.cvut.cz/graphs, repo csat-d20-data

Context where the data are (most-likely it is sufficient to take from default context):
http://onto.fel.cvut.cz/ontologies/csat-maintenance/time-analysis-2021-10-28

A/C:

• all is prepared to create jenkins deployment pipeline

profese.xlsx

• we will be able to show part of the dashboard "Access workorders"

Goal of the ticket is to describe:

• what belongs to ms: / cm: ontology
• in what namespace will entities of the ontology belong
  • e.g. within cm: ontology are we allowed to use ms: or ufo: namespace or we will define our own properties ?

Within time-analysis and presence CSV transformation I have cm:presence and cm:work-session events that are spawning two days. I need to split those events into two subevents.

Create plan entity API - see #43

• plan type - one of (work package, phase, general task type, task card, work session)
• time frame - start and end date/duration,
• plan code - used to connect to CSAT ISs, e.g. work package id
• plan title - for example WP title,
• parent plan - work package plan have no plan parents

Read plan entity API

• read plan according to plan POJO/JOPA model

Update plan entity API - see #44

• create API to update each relation in the plan model
  • parent-child relation
  • relation to resource entities, e.g. mechanic, scope, aircraft, aircraft part,
• create API to update basic properties of plan entities - for example, time frames, title, code, as well as other entities.

Delete plan entity API - see #45

• delete plan - deletes the plan entity from the system, delete relation to parent plan if it exists, delete the direct and indirect child plans.

@blcham, @LaChope

• implement basic CRUD of resources
• implement CRUD API for the relation between plan and its resource.
• for a given resource get its allowed sub resources, e.g. aircraft has specific areas, aircraft areas are maintained by some mechanic groups, mechanic groups have specific mechanics.
  @LaChope @blcham

In workpackage OK-TSR%2FH-22 AV10Y, there are 4 phase plan and one task without label. Is it possible to investigate it?

Current state:

• email with scope names and labels is not processed
• some scopes are not defined in csat-maintenance ontology but occurs in CSV files
• it is not clarified how it should be transformed in domain ontology

Only some of the task card definitions are matched 1:1 with task card reference codes in time analysis data set. This ticket should resolve the questions:

• How to match the rest of the task cards references?

One possibility to match codes is using prefix matching. This matching results more than one matches for many task card codes in task card definition files.

• Is it safe to assume a task card definition is the same for all task card references with which it matches?

Many TC definition codes which match by prefix more than one TC code references in time-analysis data

To view examples of this problem

• open file tc-def-match-prefix-based.xlsx
• filter column m-match-left to show only "T" values.
• order by column tc-left

Column description of the tc-def-match-prefix-based.xlsx file

• tc-left - TC code from tc-definition
• tc-right - TC code from time-analysis data
• s-match - T if left matches right, F otherwise
• m-match-left - T if there are multiple right matches for the same left, F otherwise
• m-match-right - T if there are multiple left matches for the same right, F otherwise

• might be done by implementing spif:parseDate

time-analysis.sms.ttl requires ?workspaceDir variable, which is absolute path.

Alternative solution:

• create module to get directory of running script
• import ontology based on url instead of filePath

Check if there are some confidential data within this repository and if so, remove it.

A/C:

• KBSS deployment is extended with new service

Create plan entity API - parent issue #38

plan type - one of (work package, phase, general task type, task card, work session)
time frame - start and end date/duration,
plan code - used to connect to CSAT ISs, e.g. work package id
plan title - for example WP title,
parent plan - work package plan have no plan parent

@blcham, @LaChope

RDFized CSV files should be deployed as well and thus provide provenance of data (should be regular part of the pipeline).

Fix the following issues

• Some properties are not loaded from application.yml
• Move initialization of EntityManagerFactory to separate configuration class

Investigate, not implement, unless trivial:

Related to WP -- OK-TSR%2FH-22 AV10Y

Follow-up the work that was assigned to Jana and clean up old way to describe columns as defined in ./aircraft-maintenance-planning-model/data/data-sample-01.

A/C:

• schema of CSV files is deployed on our graphdb server
• descriptions of columns are part of the schema
• data-sample-01 is removed/obsolete

Current version of Annotace does not work with Spark NLP profile in english (optionally investigate czech language as well), please investigate and describe it here. It used to work in previous versions.

Time-analysis dataset have attributes of ufo:objects that are changing. We have issue with that in Dashboard, because we get only dataset that is 1 day old and always changing.
Possible solutions:

1. don't do anything [currently CHOSEN SOLUTION]
   • ask CSAT to give us bigger window of time-analysis dataset and within Dashboard always replace the data
   • TODO find out when ufo:objects will not change anymore (workpackage = closed ?) and persist only those
2. represent ufo:object changes using ufo:events
   • TODO complication: transformation of CSV file will need previous state to detect changes
3. represent ufo:object as their snapsthots
4. represent ufo:object using situations

Delete plan entity API - parent issue #38
delete plan - deletes the plan entity from the system, delete relation to parent plan if it exists, delete the direct and indirect child plans.

Data regarding the task card definitions in the rdf4j repository csat-data is incomplete and uses old schema.

• Update task card definitions in csat-data rdf4j repository to use the new schema.
• Fix query task-types-definitions.sparql that fetches task card definitions to use the new schema.

This is list of issues. Let's discuss them first and then we will implement.

    <http://onto.fel.cvut.cz/ontologies/ufo/complex-event> rdfs:subClassOf [ a owl:Restriction ;
            owl:onProperty cm:has-scope ;
            owl:someValuesFrom cm:maintenance-group ],
        [ a owl:Restriction ;
            owl:onProperty cm:task-type-identifier ;
            owl:someValuesFrom xsd:integer ] .

    cm:task-type a owl:ObjectProperty ;
        rdfs:label "task type" ;
        rdfs:domain cm:maintenance-task ;
        rdfs:range cm:maintenance-task .

What is the purpose of this file:
aircraft-maintenance-planning-system/aircraft-maintenance-planning-model/aircraft-maintenance-planning.ttl

Can we incorporate it into existing structure?

From Andrej:

On GD I have uploaded statistical evaluation of CSAT data [1], done by Vlado Socha. The stats contain boxplot data, units are relative mili-seconds (from the beginning of the WP), I believe that we should consider for the beginning mean or median for both variables, and see what it does in the planning component. Vlado also provided us with file [2] showing which rows in the data he received from Bogdan contain no data and are not considered in the statistics.
[1] https://docs.google.com/spreadsheets/d/1i_Rt-fpCQISDJx-i1RkfxYvosyGWp1qy/edit#gid=523122002
[2] https://docs.google.com/spreadsheets/d/11ryuhj7mTDrdsZqxkuNW1wMBGF54KXQ_/edit?usp=drive_web&ouid=117908106743864509009&rtpof=true

Methods in the DAO layer should throw exception wrapped in PersistenceException.java

Here is the list of task card codes which is used in more than one task card definition.

250000-001/1.0 - used in work sessions

• each definition has a different MPDTASK value

    	250000-001/1.0
    	250000-01/1.0
  

572007-01-10/1.0 - used in work sessions

• each definition has a different MPDTASK value

    	572007-01-10/1.0
    	572010-01-10/1.0
  

575165-01-2/1.0

	- the task is defined for several ATA codes	
		57-50
		57-51
		57-52
		57-53

Add new properties and classes used in the JOPA model to the application ontology.

The JOPA model has errors which prevent the initialization of the EntityManagerFactory.

• add missing data and object property annotations on entity fields.
• add missing Transient annotations
• fix issues with entity inheritance
• fix issues with generic properties,  AbstractEntity.id, AbstractComplexPlan.planParts
• JOPA entities should have hashCode and equals based on their entityURI property

TSV file should be there.

Incorporate following constraints into the ontology.

WP = seznam wo
project = seznam wo
project patri prave do 1 WP
wo patri prave do 1 projektu
project ma prave 1 operatora
operator ma prave 1 limitType - toto nemusí vždy platit,
tabulka už je pro to upravena
wo patri prave do 1 TC

• fix time-analysis scopes
• create pipeline for presence