Review Comment:
SUMMARY
This paper discusses how Festo describes the components they use for Electric Drive Trains such as controllers, motors, mechanical parts, etc. with knowledge graphs through a declarative approach with the use of standards. They apply OWL/SWRL reasoning for verifying conditions when checking if components are compatible with each other and R2RML to generate knowledge graphs from their RDB. ShEx to validate the quality of their knowledge graphs. Using these knowledge graphs, they built a tool to query these knowledge graphs using SPARQL and make it easy for domain experts to find and select components matching consumers’ requests. This way, domain experts do not have to manually check and find components that are compatible to reduce the chance of selecting incompatible components and speed up the process.
GENERAL COMMENTS
This paper is properly written and provides a detailed overview of how Festo incorporated Semantic Web technologies to select the right Electric Drive Train components given a consumer’s request.
A) QUALITY, IMPORTANCE, AND IMPACT
Their application covers millions of components with an in-depth selection process where quality standards must be adhered to at all times; therefore, traceability is provided. This paper shows how important it is for the industry to provide standards of Semantic Web technologies for adoption. The in-depth use of standards shows the sustainability and maintainability of their application for the next few years. This applied approach impacts the work of domain experts and users as they can quicker find the right components while adhering to high quality standards which are automatically verified through reasoning.
B) CLARITY AND READABILITY
The authors explained well the domain-specific parts e.g. electric train drive components and systems before going into the details of modeling them in an ontology, generating a knowledge graph, etc. Therefore, it was easy to understand for non-experts how these components are modeled in the ontology and can be verified if components are compatible. The paper was clearly written overall, but it was not really clear which Semantic Web technologies were used in various steps of the ETL process they explain e.g.: (R2)RML is mentioned in Figure 5 and the text below the figure, but the paper only discusses the transformation of relational databases during the ETL process. It would be useful to discuss more in-depth how RML or R2RML is involved in the ETL process. Same for ShEx/SHACL, it is mentioned in Figure 5, but throughout the paper only ShEx is mentioned. While well-written overall, it still needs proof-reading to rephrase some sentences and correct various typos (see detailed comments).
C) PROVIDED DATA AND ITS SUSTAINABILITY
The paper only links to a datasheet about spindles which are used as an example to explain how such components are modeled in the Festo knowledge graph. The datasheet is important for non-experts to understand the type codes used in the paper such as “ESBF-BS-32-%%-P”. It would be beneficial to provide this datasheet under a sustainable IRI or repository because components get replaced when they are End of Life and so might be the datasheet when the component is not available anymore.
DETAILED COMMENTS
A) ABSTRACT
I am missing the bigger problem in the abstract that this application solves for Festo, for example: higher customer satisfaction by faster selection of electric train drive components for a consumer’s request while adhering to high quality standards.
B) MOTIVATION
The motivation section clearly explains why Festo wanted to model these components and build a knowledge graph and discusses how the paper is structured. The motivation explains in-depth what I was missing in the abstract.
Typos
- “such as a pick-and-place application, furthermore has to comply”: drop “furthermore”
- “by means of the Festo Semantic Platform”: “the” is missing. “by the means of” could be replaced by “through” for conciseness.
C) THE FSP PRODUCT DATA MODEL
The authors introduce the domain-specific terminology and how their model is used in reasoning to verify if components are compatible regarding features, technologies, etc. Later on, an example is given a spindle with its datasheet. The example clearly explains how the modeling happened, but I would like to see a more detailed explanation of Figure 3 to better understand how the different components relate to each other in the data model. The interfacing is explained shortly in the text, but does need to be better aligned with the figure. A possible solution would be adding an example of how components and their interfaces are modeled. Currently, only the interface name e.g. M-C and C-M is given but not how the interface looks e.g. voltage range, mounting holes, etc. Moreover, a more detailed figure explanation would be preferable to make the figure standalone while trying to avoid the blurred parts which makes me wonder why they are not removed from the figure if they are not relevant for the explanation.
Typos
- “range from motor with integrated controller”: add “a” or make “motor” plural.
- “non dismountable”: hyphen missing
- “interface structure in between the other”: “in” should be dropped
Rephrase: “With reference to the encoder example the following axiom rendered in Turtle syntax is”
Reference & links
The authors mention negation as failure (NAF) as a non-standard extension of SWRL, but no reference or link is provided.
D) DATA PIPELINE AND LIFECYCLE
The authors mention here the use of RML or R2RML but only transform data from relational databases. They do not explain which standard they now actually use; this part needs to be revised. From the example under 3.2 Data Mapping and Enrichment, I think it is R2RML only as I don’t see any RML extensions of R2RML in the mappings.
Figure 5 mentions ShEx/SHACL for quality validation, but the paper only mentions ShEx. The paper would benefit from a ShEx example matching the R2RML mapping to see the complete pipeline.
Later on, the authors mentioned how stable IRIs are generated using stable IDs or hashing to differentiate between revisions of components. I was wondering how revisions are handled by the system. If a new revision makes the previous ones obsolete, how is that being taken care of? This is important when providing a setup to consumers at a certain point in time, which may require different revisions of the components when placing an order.
In the enrichment explanation, the authors mention “compare with the protection level IP65 classification above”. However, I couldn’t find anything related to IP65 in the section. I think an example is missing in the previous parts of the paragraph which they are referring to.
In 3.6 Deployment and Use, the authors mention versioned knowledge graphs, how did the authors handle versions? This is related to the revision comment above.
Typos
- Rephrase: “Small errors can multiply an have an impact on large number of inferred drive trains”
“apporach”: typo
- “does not conform this standard”: “to” missing
- Rephrase: “this as next evolution step”
- Rephrase: “as it offers means for declarative description”
- “The highlighting show all directly or indirectly”: shows
E) APPLICATION: ELECTRIC MOTION SIZING
This section explains how this knowledge graph and reasoning impacts the consumers and domain experts of Festo. They developed a tool to find the right components given the consumer’s request, available components, etc. Through Semantic Web technologies, candidate components are provided and verified if they match physically with each other. This saves time and improves quality as validation is applied automatically during the process.
Behind the application, SPARQL is used in which mathematical operators and equations are applied to adhere to the laws of physics when proposing candidate components. Parts of the equations here require consumer’s input so they have to be computed at runtime. It would be interesting to see how this scales when the electric drive train setup is huge and contains a lot of these equations.
Typos
- “Filter Query Service is built up from a query”: drop “up”
- “Oftentimes”: typo
- “don’t”: do not
- “In principle, the well known formula F = m*a applies”: I would rephrase it, e.g. “In principle, Newton’s Second Law of Motion formula applies: F = m * a”
F) LESSONS LEARNED AND FUTURE WORK
The authors explained well how they established this data model, knowledge graph and tool and what they learned during the process. They also explain the next steps for their approach such as extending to other domains such as pneumatic linear motion. This will be important to establish an ontology which can cope with the different kinds of linear motion technologies.
G) MISCELLANEOUS
Typos
Shape Expressions’ abbreviation is written as “ShEx” instead of “SHEX”.
“as well as” is used a lot and can be dropped in various places through the paper
References & links
References to standard e.g. OWL, SWRL, R2RML, ShEx, etc. are missing
DECISION
Major revision
The paper is well explained, shows how important Semantic Web standards are for the industry, and how knowledge graphs and reasoning can be used to speed up the selection of electric drive train components while still adhering to high quality standards. However, the paper needs to be revised first to include a good running example across the whole pipeline as mentioned in the detailed comments.
|