Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Open Services for Lifecycle Collaboration (OSLC) - Extending REST APIs to Connect Data

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité

Consultez-les par la suite

1 sur 24 Publicité

Open Services for Lifecycle Collaboration (OSLC) - Extending REST APIs to Connect Data

Télécharger pour lire hors ligne

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.

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.

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Open Services for Lifecycle Collaboration (OSLC) - Extending REST APIs to Connect Data (20)

Publicité

Plus récents (20)

Open Services for Lifecycle Collaboration (OSLC) - Extending REST APIs to Connect Data

  1. 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. 2. About Me - Fernando Lopez 2 Machine learning Graph Mining Graph Theory Link Prediction Natural Language Processing Koneksys
  3. 3. Koneksys Consulting Services Connecting data using standards ● Custom software development for organizations and vendors ● Research projects 3
  4. 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. 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. 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. 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. 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. 9. Navigable Engineering Graph 9 Click on related test case and see test case representation Click on related model and see model representation
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. To Learn More http://oslcfest.org/ 22 https://open-services.net/
  23. 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. 24. Thanks and get in touch! fernando.lopez@koneksys.com

×