Presentation on Open Services for Lifecycle Collaboration (OSLC) at the International Semantic Web Conference (ISWC) 2019 in Auckland, New Zealand. Engineers need graphs for traceability. Problem: it is currently not possible to build engineering graphs at scale due to data and API heterogeneity. This problem can be solved by standardizing APIs of data sources. OSLC defines a standard API by combining concepts of REST and Linked Data. OSLC has been adopted by vendors of engineering software but more adoption is needed to increase the network effect.

1. Open Services for Lifecycle Collaboration -
Extending REST APIs to Connect Data
18th International Semantic Web Conference
Auckland, New Zealand
Axel Reichwein and Fernando Lopez, Koneksys
October 29, 2019
1

2. About Me - Fernando Lopez
2
Machine
learning
Graph
Mining
Graph Theory
Link Prediction
Natural Language
Processing
Koneksys

3. Koneksys Consulting Services
Connecting data using standards
● Custom software development
for organizations and vendors
● Research projects
3

4. Status Quo in Engineering Information Management
According to David Meza, Head of
Knowledge Management at NASA
● Most engineers have to look at 13
different sources to find the
information they are looking for
● 54% of our decisions are made with
inconsistent, or incomplete, or
inadequate information
Connected Data London, 2016
Quote from https://www.youtube.com/watch?v=QEBVoultYJg
4
URLs of reused images related to architecture, 3D, control

5. Challenge: Crosscutting Concerns Across Disciplines
5
Requirements
Engineering
Design Manufacturing Operation
Traceability
Impact analysis
Configuration
management
Change
Management
URLs of reused images related to requirements, design, manufacturing, operation

6. Example Relationships in Engineering
6
Requirement
Test
Case
Simulation Model
3D Model
FEDERAL AVIATION ADMINISTRATION (FAA)
Title 14, Chapter I, Subchapter C
§25.121
...(a) Takeoff; landing gear
extended... the steady
gradient of climb...not less
than 0.5 percent...for four-
engine airplanes
<<requirement>>
Climb: One-engine-inoperative
Perform simulation under
conditions...
<<testcase>>
Climb: One-engine-inoperative
Requirement
Test
Case
3D Model
Simulation Model
Control System Model

7. Graph for Describing All Relationships
7
Requirement
Test
Case
Simulation
Model
3D Model
Graph nodes represent any data
element, such as a project, a
model, or a parameter inside a
model, or a requirement etc.
Control System Model
Graph edges
represent
relationships, having
a type and a direction
depends_on
depends_on

8. Engineering Graph for Global-Level System Analysis
8
I want to understand
the impact of
changing this
requirement
I want to understand
how this requirement
is implemented
I want to go through
what-if scenarios to
find the best
architecture
I want to understand
the origin of a product
failure
System EngineerRequirement Engineer
Quality EngineerMechanical Engineer
Engineering
Graph

9. Navigable Engineering Graph
9
Click on related
test case and
see test case
representation
Click on
related model
and see model
representation

10. Configuration-Managed Sub-Graphs and Eng. Graphs
10
Requirement Project X
Version 1.3
Test Case Project Y
Version 3.0
Control System Model
Version h56278d33
Each engineering
data element belongs
to a sub-graph which
is under version-
management

11. Composable Engineering Graphs
11
Engineering Graph of
Subsystem 1 version 4
• Requirement Project A
• Test Case Project B
• Simulation Model C
Engineering Graph of
Subsystem 2 version 7
• Requirement Project D
• Test Case Project E
• Simulation Model F
Links between
data elements of
Subsystem 1 and
Subsystem 2
Engineering Graph of
System version 1
• Requirement Project A
• Test Case Project B
• Simulation Model C
• Requirement Project D
• Test Case Project E
• Simulation Model F
• Links between data
elements of Subsystem 1
and Subsystem 2

12. Steps for Building Engineering Graph
12
Data sources
Data in a common graph
format conforming to
common vocabularies for
generic data aspects
Engineering Graph
Data
transformation
Ingesting
graphs into one
single graph
and adding links
API 1
Data
Source 1
API 2
Data
Source 2

13. Challenge: 500+ Different Data Transformations!
13
Data sources
Data in a common graph
format conforming to
common vocabularies for
generic data aspects
Data transformation 1
API 1
Data
Source 1
API 2
Data
Source 2
500+ Different Data Sources
500+ Different APIs
Many different vocabularies
for the same concepts
Implementing 500+ different data
transformations is a challenge
Data transformation 2

14. Status Quo - No Complete Engineering Graph
Many data silos
Many links captured in non-
machine readable
documents
Problems are discovered
late in the design process,
and the later they are
discovered, the more
expensive it is to fix them
14

15. Standard API to Reduce Data Transformation Effort
15
Engineering Graph
Ingesting
graphs into one
single graph
and adding links
Data
Source 1
Data
Source 2
No need for data
transformations
Data and API heterogeneity problem
reduced to API-compliance problem
Standard API
Standard API
Data in a common graph
format conforming to
common vocabularies for
generic data aspects

16. Standardized Generic Data Aspects
16
Data
Source 1
Data
Source 2
Standard API
Standard API
Data in a common graph
format conforming to
common vocabularies for
generic data concepts
Generic Data Concepts
Standardized by OSLC
• Data identifier
• Configuration/Version-
Management
• Change events
• Data model/constraints
• Data containers/projects

17. Standardized Discipline-specific Concepts
● Some discipline-specific RDF vocabularies
are defined by OSLC to support data
interoperability
● Discipline-specific RDF vocabularies
defined by OSLC are not the main
contribution of OSLC!
● General Problems of discipline-specific
standards/vocabularies: likely to change
over time, and lack of consensus
17
Discipline-specific Concepts
Standardized by OSLC
• Requirements
Management
• Quality Management
• Asset Management
• Automation
• Architecture Management
• Performance Monitoring

18. OSLC API compared to traditional REST API
18
API/Data Concept Traditional REST API OSLC API
Protocol HTTP HTTP
Resource identifier
format
Often internal ID like an
integer number
HTTP URL, as in Linked Data (always
dereferenceable and always unique)
Resource
representation format
JSON (key-value pairs) RDF (JSON-LD, RDF/XML, Turtle,
etc.)
Documentation of API
endpoints
OpenAPI “RDF-version” of OpenAPI defined by
OSLC Core Discovery Spec
Resource schema
format
OpenAPI or JSON
Schema or not available
OSLC Shapes or SHACL

19. OSLC Enables New Mashup Applications
19
Data
Source 1
Data
Source 2
Standard API
Standard API
New Mashup
Applications:
• Full-text search
• Visualization
• Reporting
• Design Review
• Link prediction
• And many more
Decoupling between data and
application by using standard API

20. OSLC Adoption – APIs and Mashup Applications
20
Data
Source 1
Data
Source 2
Standard API
Standard API
50+ OSLC APIs for
different data sources
Existing OSLC-based Mashup Applications
Vendor Application
IBM • Lifecycle Query Engine
• Global Configuration
Management
• Jazz Reporting Service
Mentor
Graphics
Context
Sodius SECollab
MID Smartfacts
PTC Integrity Modeler

21. OSLC Adoption - Pros & Cons
Pros
Started in 2008. Used by major
aerospace and automotive companies
Similar to the recent Solid initiative
led by Tim Berners-Lee
Many open-source OSLC solutions at
Eclipse Lyo
Cons
Surprisingly not known to the
Semantic Web community
No support from software vendors
who fear losing vendor lock-in
OSLC considered complex. Better
documentation and demos needed
21

22. To Learn More
http://oslcfest.org/
22
https://open-services.net/

23. Conclusion
Engineers designing complex systems need
traceability, thus engineering graphs
Building (engineering) graphs at scale
requires an API standard
OSLC is an API standard combining concepts
from REST and Linked Data
We need to build graphs in other domains like
healthcare
23
Data
Source Standard API

24. Thanks and get in touch!
fernando.lopez@koneksys.com