Trip Report - INCOSE IS 2014 Systems Engineering meets (needs) open integrations + 2025 vision

I was fortunate enough to be able to attend the INCOSE International Symposium (IS) 2014, an event I've never been to before.  I've been spending more and more time over the years with Systems Engineering, it was good to learn more, share a bit more what it going on with OSLC and related topics, catch up with some friends and help some implementors lay out a plan.

One of the things that struck me as interesting is how the speakers and attendees referred to OSLC.  I'm used to seeing so many presentations over the years defining it, spelling out what the acronym means, etc.  At the IS, there was none of that.  It was just referred to by name, as everyone knows clearly what it is.  I didn't hear anyone asking or taking a note to look it up later.  OSLC was often referred to as an area which showed great promise for SE tool interoperability: as a protocol to exchange data, a way to define a minimal data model at web scale and simple ways of doing UI integration.

We had an impromptu meet up at lunch for OSLC, we in fact had too many people at the table (and yes I was the only IBMer).  It included people from PTC, Atego, JPL, Deere, Koneksys, Eclipse Foundation. Great discussion to share peoples interest, share what things are in motion and look for a way to coordinate all the activity going on in all the different places: INCOSE TII, OASIS OSLC, OMG OSLC4MBSE and more.  Looking forward to following up with this group and seeing how it advances.

I was able to give an overview and update on OSLC to an audience the represented many industries: automotive (2), air & space (2) and large machinery.

An interesting piece of work that I received when I registered what INCOSE's System's Engineering Vision for 2025, specifically these items:

• Foundations and Standards (p. 20) 
  "This systems engineering body of knowledge today is documented in a broad array of standards, handbooks, academic literature, and web-resources, focusing on a variety of domains. A concerted effort is being made to continually improve, update and further organize this body of knowledge. "
• Current Systems Engineering Practices and Challenges (p. 20-21) practice areas of "Modeling, Simulation, and Visualization", "Design Traceability by Model-Based Systems Engineering" which highlight the growing needs around improved tools and tool interoperability.
• Leveraging Technology for Systems Engineering Tools (p. 30)
  Discusses the need to move towards a set of tools that allow for: "high fidelity simulation, immersive technologies to support data visualization, semantic web technologies to support data integration, search, and reasoning, and communication technologies to support collaboration. Systems engineering tools will benefit from internet-based connectivity and knowledge representation to readily exchange information with related fields."

I'm hoping to make it to Boston around September 10th to run an OSLC workshop for the INCOSE community, stay tuned.

OSLC's relationship with Semantic Web technologies

The technical basis for accessing data through OSLC has its roots in Linked Data, which has its origins with Semantic Web technologies.  Some worry about the costs of supporting this for some simple integration scenarios, though OSLC only depends on a small amount of it.  For those that bought into the full stack of Semantic Web technologies for various domain solutions realize there is tremendous value in what it can provide but that it also comes at some cost.  The cost is in aspects of Semantic Web such as reasoners, inferencing, search engines, RDF and specialized repositories for dealing with these things.

OSLC takes a minimal incremental approach to depend on only what is needed to satisfy the integration scenarios.  So far that has led us to leverage a simple standard way of describing resources using RDF.  That is about where the Semantic Web technology dependency ends.  We leverage a few terms out of RDF Schema to help with defining our own vocabulary terms but do not go beyond that as it might imply that clients would need to process inference rules against the resource representations they receive to learn more.

Since a primary goal of OSLC is to not reinvent but leverage standards based approaches that meet our requirements, I can see cases where it might be good to adopt some more Semantic Web technologies.  Though to be clear, for tools to get value out of OSLC-based integrations, only some RDF syntax readers and writers are needed.  There is no need for tools to have be rehost or rewrite them onto a new technology base, they can simple adapt their solution with a simple fasade or update their existing REST APIs to provide this support.