View source for Blog:Contexts for Integration and Interoperability

{{Blog
|Purpose=This track examines the advantages of explicit contexts for the purposes of integration and interoperability.
}}

== Definitions overview ==

Integration has become almost a way of life for many organizations. Over the last few decades there has been an explosion of information and uses thereof, usually with the aid of computers. As information has become more 'computerized' the systems that provided or supported the use of information were created based on the prevailing needs of a domain or organization (i.e., the time horizon of the needs was short, or scope of possible uses too small). But the uses of information evolved more rapidly than the supporting systems requiring an ability to 'reach' across those information systems to meet the new needs: integration. With the need to integrate systems the issues of interoperability arose: it wasn't as neat as using Lego blocks.

Operationally, interoperability has many perspectives or 'dimensions', more than just technical (e.g., social, cultural). There are several models that attempt to describe interoperability. The LISI model from MITRE (www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/) or the SCOPE model from NCOIC (http://www.ncoic.org/images/technology/SCOPE_MODEL_VER1.0.pdf). Each of these models for interoperability attempt to capture aspects of the entity or entities that are needed to interoperate and their context. However, though specific technical or syntactic problems can be overcome the continuing issues are semantics. How can the symbols and terms used in the communication among the entities be made sufficiently explicit and usable for both machines and humans to ensure consistency of interpretation. 


Different Notions and meaning of context and context-content and Semantic and syntactic aspects of context were presented or referenced in various papers, efforts and deliberations.

For example, the Paper by Pat Hayes considers in great depth the two schools of thoughts and describes Physical, environmental, textual / linguistics aspects of context as well as External (EL) and Internal (IC) representation of context, meaning and understanding when it is NL based and when it is not. The paper also discusses context logic and meaning of “ist” notation. Hayes also analyses the context, semantics and syntax in arriving at linguistics meanings and textual understanding and admits the complexity of representing IC models and refers works of Guha, Buvac and others attempting to analyze context logic.
Even though not discussed the topic of our understanding meaning or content of a topic is dependent on the medium of expression or presentation such as Text, Audio, Visual, graphic, Logic etc. If a person grows learning language A and is working in language B, the meanings are translated or transliterated by a complex internal context (IC) that implicitly involves grammar, vocabularies and contexts relating to both A and B to be able to understand and communicate or publish the topic under consideration.

John Sowa also analyzes context and provides definitions presented in Summit Blogs, presentations and discussions the central theme being context is at Meta Level but not necessarily the content. He also emphasizes the dynamic nature of context. He and other speakers at the Summit sessions speak of Micro-theories, Category theory, Object Process Model, etc.

== Content Draft for communique' ==

Integration has become a way of life for many organizations. Over the last few decades there has been an explosion of information and uses thereof, usually with the aid of computers. As information has become more ‘computerized’ the systems that provide or support information are created based on the prevailing needs of a domain, organization, or application resulting in a constrained timeframe and perspective – not with the expectation of integration and reuse. As stated by [Hans Polzer], different systems embed different contexts, purposes, and scope decisions by different institutional sponsors.

While these systems are defined and built independently, integration of their information and processes is essential for collaboration, shared services, information sharing and analytics. These capabilities are not optional in today’s world, they are essential for the continued existence of commercial enterprises and the effectiveness of government.

Each system, organization community, database or message format is thus defined in its own context which implicitly depends on other context. Integration and interoperability is the practice of sharing information or instructions across these different, independently conceived, systems context. The context in which these systems are conceived assumes other contextual dimensions, many of which are unstated. Different unstated context result in different unstated assumptions in interpreting information and instructions across systems, resulting in error and risk.

This implies the practice of integration and interoperability is one of dealing with multiple context, understanding their similarities, differences and relationships, and mitigating those differences and potential error and risk. As [Dean Allemang] presented, current practice depends on ontologists to understand and bridge these contextual differences, which can be successful for a particular problem. However integration and interoperability at scale suggests that the applicable context and their implications be more formally stated such that automated reasoning can support, validate and in some cases replace human intervention.

Specific contextual assumptions that may differ across systems and data sets include but are not limited to:

**•	'''Time:''' Consider a Database that represents history integrated with one that assumes the “current” point in time, the time assumptions of one must be integrated with the other. Or, consider an organization that has a policy for how long a measurement (e.g. of weight) may be considered the weight on an individual.

**•	'''Spatial:''' Consider ontologies that are built assuming a context of the surface of the earth Vs. the needs of a space agency. On the earth a location can be specified by latitude, longitude and altitude – this does not work well in space. On earth there is a (reasonably) constant acceleration of gravity, obviously not so in space.

**•	'''Trust:''' While it is common for ontologies to consider assertions as absolutes, information differs  in its trustworthiness based on both the source and the interpreter. Provenance and the relationship between provenance and trust impact what information may be integrated and with what expectations.

**•	'''Terminology:''' Different communities and systems will use different terms to refer to the same concept and the same terms may refer to different context. Some communities are imprecise as to the meaning of terms.


The above are just examples of the many dimensions of context that may differ across systems being integrated [Casanave]. As ontologies are able to specify their contextual assumptions logic can be applied to cross the contextual boundaries.

Methods for representing and reasoning about context have improved, as is shown in other sections of this Communiqué, but we have yet to see well defined and generally accepted best practices with a formal grounding.

Operationally, interoperability has many perspectives or ‘dimensions’, more than just technical (e.g., social, cultural). There are several models that attempt to describe interoperability. The Levels of Information Systems Interoperability (LISI) model from MITRE (Levels of Information Systems Interoperability (LISI), 1998) or the Systems, Capabilities, Operations, Programs, Semantic Modeling for Information Federation (SMIF), and Enterprises (SCOPE) model from the Network-Centric Operations Industry Consortium (NCOIC) (Creps et al., 2008). Each of these models for interoperability attempt to capture aspects of the entity or entities that are needed to interoperate and their context. However, though specific technical or syntactic problems can be overcome there are continuing issues concerning expression of and reasoning about context. As context tend to be higher order, some first order logics may not be sufficient, further complicating reasoning tasks.

Formally stating context and its implications with the requisite reasoning for reducing the time, cost and risk of integration and interoperability remains a topic for further validation and research. The fundamental question is; How can the symbols and terms used in the communication among entities and different context of usage be made sufficiently explicit and usable for both machines and humans to ensure consistency of interpretation? 

'''Crossing contextual boundaries'''

Where ontologies or systems are independently defined with differing context and terminologies, how are the contextual assumptions of the various systems made explicit and how can processes and information defined in separate context joined into a common “system of systems” that retain semantic integrity while reducing time, cost and risk?

'''''Elaboration'''''

The Topic of this blog is context - integration and interoperation, for which introductory paragraphs from Todd Schneider and others are included in the blog earlier as well as semantic Framework discussed by Cory Casanave. In the background we keep in mind that we are attempting to scope this for developing or using ontologies in various domains, applications and systems for practical benefits.

If context is dynamic and content (domains, applications and systems) also for example changes, e.g.  both temporally and in narrations, then it is like moving target in a moving window being pursued from a moving platform, just to give an analogy. For integration, context may sometimes be amenable to hierarchy or subset of overall context and content may often relate to domain or subdomain. But external environment and physical or timeframe changes require synchronization, alignment and achievement of integrated ontology and related context. For inter-operation among different ontologies, the metalevel contexts need to be aligned (synchronized or vocabularies be overlapping or be translatable) before meaningful interoperability of contents (ontologies, applications, systems).

In a simple example, the automotive ERP application has to be context aware of make and model of the resulting Vehicle, and content may be just the parts list or delivery synchronized at the assembly line at the time of manufacture, hence one gets the idea that databases, systems and clocks have to be synchronized and time stamped for meaningful inter-operation of the intended content or vehicle.


==== '''Summary of February 21 and March 21, 2018 Sessions
Track: Context - Integration and interoperability'''  ==


== Feb 21, 2018 ==

'''Eswaran ‘Sub’ Subrahmanian and Ira Monarch (NIST, CMU) on


Root and rule-based approach to search and knowledge representation given extensible and evolving terminology.''' 

'''Sub:'''

There is no General theory of Modeling -  part of it is concentration on theory as in science, model-based engineering is recent. You need multiple models.
Domain based such as Genome project, later others. Automated search, structuring ontology and discovering new trends are goals.
NIST has huge number of repositories – Manufacturing, Cell biology, IT etc. Integration of search from thesauri, libraries, databases and ontologies, etc. Building domain ontologies, use of engineering, one two many nouns and verbs are modified and conjugation in Sanskrit. 
Concepts of super roots, WASP is molecular modeling software, for many roots, ordering is important.
Need of classifier, Manufacturing archive, alloys, Al-Mg alloys combinations in search, focus domain.

'''Ira Monarch:''' 

Cybersecurity example. Phrases in addition of words in search, databases used CVE common Vulnerability Database, referred to MITRE - NIST Collaboration, patterns in textual data to discover frame from phrases, exploring vulnerability, deriving a schema, use it proactively, type of attacks prediction based on probabilities, using the content of CVE and analyzing, Denial of service (DoS) gives no keywords, so constructed words based schema, using text analysis, 80% common ways of linking with this schema from 21k searches were the example discussed. Attackers and many attack types were shown, and methods enumerated. 
Used for Taxonomy and ontology generation.

'''Discussion:'''

Pieces of Linear combination, we start linear for simplicity.
Q-How can you integrate domains? Material as domain and classifier.
Classifier Classified: from roots and roots model – Ref: Bhat, Sanskrit: Gaccha “to go” verb, modifiers Gacchati, Gacchanti, etc. 
DOS is OS and Denial of Service same abbreviation. Dis-ambiguation? Yes - it is possible.
Q-	Word Vulnerability, examples that we know about, but inside the system code to be executed? Are real-vulnerability, (does not zero in) on strong vulnerability in terms of code related vulnerability. Yes.
This study concentrates only on NLP but code related rummaging is a perhaps a separate Project.
Q-	 N-ary relationships? Yes - hoping to uncover.

Q-	Talking to Journals, they do not have, ways of incrementally searching. Federal Reserves, trying to use ontology and Indexing as they deal with several hundred documents per day.
NIST (Dr. Ram Sriram) is integral to this Project and one of the participants is German and knows their Grammar etc.
Q-	Do they have a model an ontology or schema, describes the relationship? 
We are discovering it bottom-up and growing out, CVE database but same underlying schema.
Cory to post a link in Chat about the OMG efforts.
Q-	 Have you compared with NLM / MEDLARS and Criminal Justice Systems?
Yes, compared with PubMed. Not anything systematic. Experimenting trying to do topic modeling like Google bag of worms.
Q-	Earlier materials work with Chambers?
Yes, familiar with their work on XML Schema, notion of combining work, some work of theirs is used in this Project.
Q-	OPM – they get fixed in assigning labels. Will Sanskrit rule help break that?
Trying to combine - Working on category theory and modeling.

== March 21, 2018 ==

 ''Focus practicality and understanding for integration and translation among them.
''
'''Hans Polzer, formerly with Lockheed Martin:'''

 Context changing events are central to Interoperability. All data may represent reality, Systems, and Data entities. Context and use of ID. Different Systems use different contexts and scope decisions. Commonality and Common Data Standards do have differences.
Hans provided definitions of Context related terms such as Frame of Reference, Domain, other attributes.
Context changing events often lead to interoperability, sometimes due to limited design scope. Assumptions such as US only can lead to errors when extending to global applicability.
Giving example of trying to find Private Ryan whose siblings are killed in war, systems are not open or available for duty location in operational areas, to locate Ryan. Another event is tsunami and global level of operational domains such as health, food, logistics, etc. Specific data representations such as granularity of data representations, geolocation, skills matching in multi-agency environment etc.
Vehicle could be automobile, drone, multirole as in military, or in accident, scope of context is important. One needs context and scope discussions for common context such as done in WSDL, community scope NCOIC type standards need to be developed. Perhaps WSDL needs to be specific with rt scope and context, attributes to be added, like the evolution of Metadata Standards.


'''Dean Allemang formerly Top Quadrant, Working Ontologist:'''  

''Two topics: Deployment at Bank of America (Merrill Lynch) CESIUM Project, and FIBO Project that followed.''

Use of RDF and Ontology objective, 3 years in operation, platform for reference data for firms and attributes such as accounts and ratings, need for knowledge of firms for regulation compliance, etc. Cesium has 4 years of operational data, sustainable extensibility such as with new databases, warehouses are not supporting extensibility.
Sharable, graphs approach, reference data were discussed. W3C SKOS and W3C Prov-O used in Cesium.
Controlled vocabulary datasets. Dodd-Frank is one primitive, similarly others in Cesium. Model Driven Platform. Main advantage of Semantic Web is use of ontology from end-end and RDF made it possible.
Ontology Browser entities were presented. Business vs system time aspect were discussed, such as bitemporal databases. Realtime and bitemporal discussed.

FIBO - Enterprise Data Management Council, Financial crisis of 2008, addressing root cause, awareness White Paper resulted in FIBO addressing risk. OWL RDF used, being like Cesium. However, in retrospect Cesium could benefit from developed definitions and entities from FIBO to address risk.
In FIBO many aspects and many masters, entities, rating, known and upcoming datasets, vocabularies, mediation and coherence, FIBO can offer views on these.
Synergy between Cesium and FIBO.

== Q&A ==

Q-	How do you define Scope 
By Domain, universally difficult. Scale is important in scope. Problem is scope creep, decision or relevance of scope.
Q-	Context in banking - are there differences?
Yes, for example, difference in roles, and in internationalization.
Q-	Time as GMT or UTC
Often problems in business and system times, period of mismatch between contracts.
Q- 	Context, MDM and ontology how related?
RDF UML have some insight in commonality, RDF layering, Cesium and FIBO use two contexts and how to manage and is main activity of modeling.
Need to make context exclusive for design vs use of tools and workflow in-time!
Process awareness is difficult.

'''Issues (i.e. opportunities leading to future work) to be listed.
'''

[[Category:OntologySummit]]
[[Category:OntologySummit2018]]