Systems Modeling Ontologies

INCOSE Model Based Systems Engineering (MBSE)

MESA, AZ Workshop
(February 5-8, 2010)

Ralph Hodgson,

CTO, TopQuadrant Inc.

NASA NExIOM Ontology Lead
 System Model Ontologies Working Group
Meeting Summary Report 2009
• Background and Motivation
– How can ontologies help with MBSE? Can they help with modeling multiple
aspects of a problem using different tools?
– Educational outreach on Ontologies - what they are, how they are used
– Connect with relevant MBSE Challenge problems
• Work to-date
– NASA Constellation Program (CxP) and NExIOM Ontologies established
modeling principles, Name and Identifier Rules and the framework for the
Ontology Architecture of the SysMO Ontologies
– NASA XML Controlled Vocabularies for Units, Data Types, Properties and
other Space System terminologies were generated from the NExIOM OWL
Models, proving co-existence strategies for OWL and XML
– First SysMO Ontology was manually created from SysML 1.0 and integrated
with the NASA System Ontology based on SBFI formalism
• Next Objectives
– Complete SysMO 1.1 generation from SysML 1.1 using TopQuadrant’s
Semantic XML, XMI Ontology and, SPIN, a Rules Language based on
W3C’s SPARQL
– Document 3 Use Cases: (1) Data Exchange between SysML tools,. (2) A
Use Case that explores the role of controlled vocabularies for data
interoperability, (3) Aggregation of information from multiple tools.
– Team with a Challenge Team to demonstrate SysMO-based interoperability
between tools
2/9/2010 INCOSE Feb 2010 MBSE Workshop 2
 Work to date (1 of 2)
ƒ INCOSE Presentation January 2008
ƒ Introduced OWL
ƒ NASA NExIOM Work
ƒ SysMO – an OWL model of SysML

ƒ DoD NATO Presentation November 2008

ƒ Semantic Interoperability using Ontologies

ƒ DoD C2 Presentation January 2009

ƒ Command and Control Ontologies
ƒ NASA NExIOM Work

2/9/2010 INCOSE Feb 2010 MBSE Workshop 3

 Work to date (2 of 2)
ƒ PDE 2009
ƒ Product Data Exchange Meeting
ƒ Boeing, WA

ƒ QUDT http://www.qudt.org
ƒ Quantites, Units, Dimensions and Types
ƒ Release of some NASA Foundation Models

ƒ XML SchemaPlus http://www.xspl.us

ƒ Specification Language for XML Schema
ƒ Retains OWL Semantics
ƒ NASA Work on Ontology-Driven Generation
of XML Schema and Controlled Vocabularies
ƒ Distributed Simulation
ƒ Telemetry, Commands and Messages
2/9/2010 INCOSE Feb 2010 MBSE Workshop 4
 OWL – think of it as XML++

• OWL = Web Ontology Language

– A language for describing a domain of
interest
– Classes of things, properties of things,
relationships between things
– A standard defined by the World-Wide
Web Consortium (W3C)
• How does it relate to XML?
– OWL can be serialized in XML
– OWL is built on the Resource
Description Framework (RDF)
– OWL constructs allow us to say things
that XML Schema does not allow

2/9/2010 INCOSE Feb 2010 MBSE Workshop 5

 Reminder:
3 Powerful Ideas about OWL
1. Subject-Predicate-Object Triples
2. Identifiers Æ Composition Construct
3. Model Schema also expressed in Triples

2/9/2010 INCOSE Feb 2010 MBSE Workshop 6

 OWL Key Idea # 1 –
“Think Triples”: Subject Predicate Object
Subject Predicate Object
hasSubSystem Reaction
Vehicle Control
system
hasComponent
Reaction
Thruster
Control
Jet
system
hasParameter
Thruster
Parameter
Jet

hasUnits
Parameter Unit

hasDatatype
Parameter DataType

2/9/2010 INCOSE Feb 2010 MBSE Workshop 7

 OWL Key Idea # 2 –
Identifiers not Names (“Everything has a URI”)
Subject Predicate Object
subsystem Reaction Control
ORION
system

subsystem Guidance &

ORION Navigation Control
System

cev:ORION rdf:type nasa:Vehicle;

cev:ORION sys:subsystem cx:RCS

+ cev:ORION
cev:ORION
rdf:type
sys:subsystem
nasa:Vehicle;
cx:GNCS

Æ Statements in different models but same URIs means

more information about the same things

2/9/2010 INCOSE Feb 2010 MBSE Workshop 8

 OWL Key Idea #3: Schema uses Triples -
queried with same Language as the models

SPARQL Query for the Namespace URI of every Class:

SELECT ?class ?ns

WHERE {
?class rdf:type owl:Class .
LET (?ns := afn:namespace(?class)).
}

2/9/2010 INCOSE Feb 2010 MBSE Workshop 9

 Capability Case: Ontology-Based Data
Exchange between Tools
Each tool’s model is converted to triples using SPIN. Triples can be related through
a unified SysMO Model. Data exchange and other operations are then possible.

SysML Tool Unified Models Another TOOL

SysML Model 1 Domain Models
SPIN SPIN OWL Model Domain Models
SysML Model Domain Models
Vehicle
+ +
System Block SpaceVehicle
Port
Component
System Block
Port + Vehicle
SubSystem
SubSystem
Param
Mapping Parameter Mapping Parameter

Rules Rules
XMI Import XMI Import

SPIN Controlled SPIN

Semantic XML Vocabularies Semantic XML
Name and Identifier Alignment
Alignment
Rules
SysML Tool 2
Tool 1 Units Data Types

Properties +

2/9/2010 INCOSE Feb 2010 MBSE Workshop 10

 Capability Case: Ontology-Driven PLM
A model that knows what information objects are consumed and produced at
different points in the lifecycle

C3I* LCS*

Test &
MS
Eval GS
Maintain
Upgrade
System
Manufacture Lifecycle
Cx Data Arch
model Lessons
Learned

Learn SIL, CAIL,

Design CxTF

Cos Ris
NExIOM
Perf
t k *
2/9/2010 INCOSE Feb 2010 MBSE Workshop 11
 Capability Case: Ontology-Driven PLM
– NASA Lifecycle Ontology Example

2/9/2010 INCOSE Feb 2010 MBSE Workshop 12

 SysMO Ontology

2/9/2010 INCOSE Feb 2010 MBSE Workshop 13

 SysMO is a formal Ontology
• SysML Ontology is pure
– no UML constructs
– Think of it as “Precise SysML”
• Superset of SysML
• Uses an SBFI Formalism
• Uses QUDT Ontologies
– Quantities, Units, Dimensions and Types
– Data Types for Vectors, Matrices, Time-series
Arrays, etc.
QUDT – http://www.qudt.org (August 2009)
SysMO – http://www.sysmo.org (March 2010)
2/9/2010 INCOSE Feb 2010 MBSE Workshop 14
 Transforming SysML from XMI to an
OWL Model
UML4SysML. TopBriadComposer
OWL Model
merged.uml UML Importer

Retains UML Metamodel -

only recommended as a
‘Proxy’ Ontology
2/9/2010 INCOSE Feb 2010 MBSE Workshop 15
 Formal SysMO Ontologies
Named Graph Graphs import other Graphs

An Ontology has a
Namespace

Graphs contribute
to one or more
Ontologies

2/9/2010 INCOSE Feb 2010 MBSE Workshop 16

 SysMO in TopBraidComposer
Class Form Properties
Classes

SPARQL
Engine

2/9/2010 INCOSE Feb 2010 MBSE Workshop 17

 SysML Requirement
Class
Properties
Subclass
Relation

Association

2/9/2010 INCOSE Feb 2010 MBSE Workshop 18

 SysML Block, Ports and Connectors

2/9/2010 INCOSE Feb 2010 MBSE Workshop 19

 SysML Block Serialization (N3/Turtle)
Subject Predicate Object

sysml:Block
a owl:Class ;
rdfs:label "Block"^^xsd:string ;
rdfs:subClassOf owl:Thing ;
rdfs:subClassOf
[a owl:Restriction ;
owl:allValuesFrom sysmo:Connector ;
owl:onProperty sysmo:connector
];
….

The ‘Object’ of this SPO is a ‘Restriction’ specifying that all values

of the ‘connector’ association must be ‘Connector’ instances.

2/9/2010 INCOSE Feb 2010 MBSE Workshop 20

 SysML Block Serialization (RDF/XML)

<owl:Class rdf:about="http://www.sysmo.org/mbse/system/sysml.owl#Block">
<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Block</rdfs:label>
<rdfs:subClassOf>
<owl:Restriction>
<owl:allValuesFrom
rdf:resource="http://www.sysmo.org/mbse/system/sysmo.owl#Connector"/>
<owl:onProperty
rdf:resource="http://www.sysmo.org/mbse/system/sysmo.owl#connector"/>
</owl:Restriction>
….

2/9/2010 INCOSE Feb 2010 MBSE Workshop 21

 SysML FlowPort

2/9/2010 INCOSE Feb 2010 MBSE Workshop 22

 FlowPort in Turtle/N3 Format
sysml:FlowPort rdfs:subClassOf
a owl:Class ; [a owl:Restriction ;
rdfs:label "Flow port"^^xsd:string ; owl:maxCardinality "1"^^xsd:int ;
rdfs:subClassOf sysml:Port ; owl:onProperty sysml:hasFlowSpecification
rdfs:subClassOf ];
[a owl:Restriction ; rdfs:subClassOf
dc:description "Indicates the direction in which an Atomic FlowPort [a owl:Restriction ;
relays its items. If the direction is set to in then the items are relayed owl:allValuesFrom sysml:Connector ;
from an external connector via the FlowPort into the FlowPort's owner owl:onProperty sysml:isSinkFor
(or one of its Parts). If the direction is set to out, then the items are
];
relayed from the FlowPort's owner, via the FlowPort, through an
external connector attached to the FlowPort, and if the direction is set to rdfs:subClassOf
inout then items can flow both ways. By default, the value is inout." ; [a owl:Restriction ;
owl:allValuesFrom sysml:FlowDirection ; owl:cardinality "1"^^xsd:int ;
owl:onProperty sysml:hasDirection owl:onProperty sysml:hasDirection
]; ];
rdfs:subClassOf dc:description "Flow Ports are interaction points through
[a owl:Restriction ; which input and/or output of items such as data, material
or some property such as torque, pressure or energy
owl:allValuesFrom sysml:FlowSpecification ;
may flow. This enables the owning block to declare
owl:onProperty sysml:hasFlowSpecification which items it may exchange with its environment and
]; what are the interaction points through which the
rdfs:subClassOf exchange is made. A FlowPort specifies the input and
[a owl:Restriction ; output items that may flow between a Block and its
environment. FlowPorts are interaction points through
owl:allValuesFrom sysml:InOutFlowProperty ;
which data, material or energy 'can' enter or leave the
owl:onProperty sysml:bidirectionalFlow owning Block. The specification of what can flow is
]; achieved by typing the FlowPort with a specification of
rdfs:subClassOf things that flow. In general, flow ports are intended to be
[a owl:Restriction ; used for asynchronous, broadcast, or send and forget
owl:allValuesFrom sysml:Connector ; interactions." .
owl:onProperty sysml:isSourceFor
];

2/9/2010 INCOSE Feb 2010 MBSE Workshop 23

 Ontology Architecture Example:
QUDT Ontologies for Units of Measure

Ontology
Imports relation

An Ontology is a namespace – a named graph can contribute to

more than one ontology

2/9/2010 INCOSE Feb 2010 MBSE Workshop 24

 NASA NExIOM Modular Ontologies
Simulation Distributed Simulation
Tool

Temporal QUDT

Some foundation Ontologies may be available subject to a NASA license

2/9/2010 INCOSE Feb 2010 MBSE Workshop 25

 Dimensions of Ontology Architecture

Organization

Domain

Discipline

Specificity

Ontologies are partitioned according to domains, disciplines,

organizations and levels of specificity. Named graphs are
aggregated through configuration ontologies according to specific
needs.

2/9/2010 INCOSE Feb 2010 MBSE Workshop 26

 NExIOM Standard Vocabulary (NSV)
Basic physical quantities, forces & moments examples

Data-Name Identifier Description Definition Symbol (Units) Units Data-Name Identifier Description Units
ForceX Fx = F ‫ ڄ‬ex ML/T2
ForceY Fy = F ‫ ڄ‬ey ML/T2
Potential Potential ‫׏‬φ = q L2/T SI
ForceZ Fz = F ‫ ڄ‬ez ML/T2
StreamFunction Stream function (2-D) ‫ × ׏‬ψ= q L2/T SI
ForceR Fr = F ‫ ڄ‬er ML/T2
Density Static density (ρ) M/L3 SI
ForceTheta Fθ = F ‫ ڄ‬eθ ML/T2
Pressure Static pressure (p) M/(LT2) SI ForcePhi Fφ = F ‫ ڄ‬eφ ML/T2
Temperature Static temperature (T) Θ SI
Static internal energy per unit Lift L or L' ML/T2
EnergyInternal
mass (e) L2/T2 SI
Drag D or D' ML/T2
Enthalpy Static enthalpy per unit mass (h) L2/T2 SI
Entropy
MomentX Mx = M ‫ ڄ‬ex ML2/T
Entropy (s) ML2/(T2Θ) SI
EntropyApprox MomentY My = M ‫ ڄ‬ey ML2/T
Approximate entropy (sapp = p / ργ) (L(3γ-1))/((M(γ-1)).T2) SI
MomentZ Mz = M ‫ ڄ‬ez ML2/T
DensityStagnation Stagnation density (ρ0) M/L3 SI MomentR Mr = M ‫ ڄ‬er ML2/T
PressureStagnation Stagnation pressure (p0) M/(LT2) SI MomentTheta Mθ = M ‫ ڄ‬eθ ML2/T
TemperatureStagnation Stagnation temperature (T0) Θ SI MomentPhi Mφ = M ‫ ڄ‬eφ ML2/T
EnergyStagnation Stagnation energy per unit mass (e0) L2/T2 SI MomentXi Mξ = M ‫ ڄ‬eξ ML2/T
EnthalpyStagnation Stagnation enthalpy per unit mass (h0) L2/T2 SI MomentEta Mη = M ‫ ڄ‬eη ML2/T
EnergyStagnationDensity Stagnation energy per unit volume (ρe0) M/(LT2) SI MomentZeta Mζ = r ‫ ڄ‬eζ ML2/T

VelocityX x-component of velocity (u = q · ex) L/T SI Moment_CenterX x0 = r0 ‫ ڄ‬ex L

VelocityY y-component of velocity (v = q . ey) L/T SI
Moment_CenterY y0 = r0 ‫ ڄ‬ey L
VelocityZ z-component of velocity (w = q . ez) L/T SI
Moment_CenterZ z0 = r0 ‫ ڄ‬ez L
VelocityR Radial velocity component (q . er) L/T SI

PDE2009 - NExIOM Slide 27 4/30/2009

 QUDT Model Example

2/9/2010 INCOSE Feb 2010 MBSE Workshop 28

 Units are partitioned into Sub-Classes

2/9/2010 INCOSE Feb 2010 MBSE Workshop 29

SI Base Quantities and Units

Slide 30
 Quantities and Units – Partitioning by
Discipline

QUD Classes
Unit Instances

2/9/2010 INCOSE Feb 2010 MBSE Workshop 31

 QUDT Controlled Vocabulary:
Units Example
<units:NExIOM xmlns:cx="https://nst.nasa.gov/esmd/cx/cx.owl"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:nc="https://nst.nasa.gov/esmd/cx/nc.owl"
xmlns:nexiom="https://nst.nasa.gov/esmd/cx/collections/nexiom-n1-n2-schema.owl"
xmlns:owl11="http://www.w3.org/2006/12/owl11"
xmlns:property="https://nst.nasa.gov/esmd/cx/property.owl"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:units="https://nst.nasa.gov/esmd/cx/n2units.owl"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://nst.nasa.gov/esmd/cx/units.owl ../Schemas/XSD_NEXIOM-units-v1.33.xsd">
<units:AbsorbedDose nc:abbreviation="Gy" nc:code="0775“ rdf:type="units:Derived,units:Si" rdf:ID="units:Gray" rdfs:label="Gray"/>
<units:AbsorbedDose nc:abbreviation="rad" nc:code="1550” rdf:type="units:NotUsedWithSi" rdf:ID="units:Rad" rdfs:label="Rad"/>
<units:AbsorbedDoseRate nc:abbreviation="Gy/s" nc:code="0780“ rdf:type="units:Derived,units:Si"
rdf:ID="units:GrayPerSecond" rdfs:label="Gray per second"/>
<units:Acceleration nc:abbreviation="ft/s^2" nc:code="0660“ rdf:type="units:Derived,units:NotUsedWithSi"
rdf:ID="units:FootPerSecondSquared" rdfs:label="Foot per second squared"/>
<units:Acceleration nc:abbreviation="Gal" nc:code="0705“ rdf:type="units:NotUsedWithSi" rdf:ID="units:Gal" rdfs:label="Gal"/>
<units:Acceleration nc:abbreviation="G" nc:code="2100” rdf:type="units:NotUsedWithSi" rdf:ID="units:Gravity" rdfs:label="Gravity"/>
<units:Acceleration nc:abbreviation="in/s^2" nc:code="1111“ rdf:type="units:Derived,units:NotUsedWithSi"
rdf:ID="units:InchPerSecondSquared" rdfs:label="Inch per second squared"/>
<units:Acceleration nc:abbreviation="kt/s" nc:code="2115“ rdf:type="units:Derived,units:NotUsedWithSi"
rdf:ID="units:KnotPerSecond" rdfs:label="Knot per second"/>
<units:Acceleration nc:abbreviation="m/s^2" nc:code="1110“ rdf:type="units:Derived,units:Si"
rdf:ID="units:MeterPerSecondSquared" rdfs:label="Meter per second squared"/>
<units:Acceleration nc:abbreviation="microG" nc:code="2110“ rdf:type="units:NotUsedWithSi" rdf:ID="units:Microgravity" rdfs:label="Microgravity"/>
<units:Acceleration nc:abbreviation="mG" nc:code="2105“ rdf:type="units:Derived,units:NotUsedWithSi"
rdf:ID="units:Milligravity" rdfs:label="Milligravity"/>
…

32
 QUDT: Time Series Array
Root for all Structured Root for all Structured Data Types
Data Instances

Making the connection

between a data value
and its parameter

A TimeSeries State Vector

Array Data Separation of Type Specifications
Structure Specifications from define number
Data of elements

33
 Example of Orion XML – Parameters
<orion:ORION rdf:ID="orion:ORION">
<orion:Property cx:cxCUI="TBD"
cx:cxFUI="orion:ORN.Acceleration_0"
cx:cxCUI="TBD“
data:type="type:FLOAT-DP"
rdf:ID="orion:ORN.Acceleration_0“
rdf:type="vehicle:Acceleration" sysml:propertyType="property:Acceleration"
units:units="units:MeterPerSecondSquared"/>

<orion:Property cx:cxCUI="TBD" cx:cxID="orion:ORN.Force_0" cx:cxCUI="TBD"

data:type="type:FLOAT-DP" rdf:ID="orion:ORN.Force_0" rdf:type="vehicle:Force“
sysml:propertyType="property:Acceleration" units:units="units:Newton"/>

<orion:Property cx:cxCUI="TBD" cx:cxID="orion:ORN.Inertia_0" cx:cxCUI="TBD“

data:type="type:Tensor3x3-FLOAT-DP" rdf:ID="orion:ORN.Inertia_0" rdf:type="vehicle:Inertia“
sysml:propertyType="property:ProductOfInertiaXY-Axis"
units:units="units:KilogramMeterSquared"/>

<orion:Property cx:cxCUI="TBD" cx:cxID="orion:ORN.Mass_0" cx:cxCUI="TBD“

data:type="type:FLOAT-DP" rdf:ID="orion:ORN.Mass_0" rdf:type="vehicle:Mass“
sysml:propertyType="property:Mass" units:units="units:Kilogram"/>

<orion:Property cx:cxCUI="TBD" cx:cxID="orion:ORN.Position_0" cx:cxCUI="TBD“

data:type="type:GlobalPositionVector" rdf:ID="orion:ORN.Position_0" rdf:type="vehicle:Position“
sysml:propertyType="property:Location" units:units="units:Meter"/>
……
34
 Ontologies for Specifications – Generating
XML Schemas and Controlled Vocabularies

GRDDL XSLT
Going from XML to OWL Generator

XSLT
Processor
2/9/2010 INCOSE Feb 2010 MBSE Workshop 35
 XML SchemaPlus – a language for
specifying XML Document Structure
<?xml version="1.0" encoding="UTF-8"?>
<SchemaPlus xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:noNamespaceSchemaLocation=“SchemaPlus.xsd">
<RootElement name="TrainingExample"/>
<ScalarElement name="SimulationTitle"></ScalarElement>
<ReferenceElement name="Unit"></ReferenceElement>
<NestedElement
name="scenario“ type="ScenarioType">
</NestedElement>
<ObjectType name="ScenarioType">
<Attribute name=“provenance”></Attribute>
<CollectionElement
name="simulationConfigurationParameter"
type="SimulationConfigurationParameterType">
</CollectionElement>
</ObjectType>
</SchemaPlus>

Retaining OWL Semantics

2/9/2010 INCOSE Feb 2010 MBSE Workshop 36
 Example of SchemaPlus:
Sensor Specification
Sensor is a ‘NestedElement at the Root level
<NestedElement name="Sensor" type="sysml:SensorType"></NestedElement>
<ObjectType name="SensorType" namespace="system" baseType="sysml:DeviceType">
<Attribute ref="data:bitsPerSample" type="xs:int"></Attribute>
<Attribute ref="data:bitsPerSecond" type="xs:int"></Attribute> Specification of an
<Attribute ref="data:samplePerSecond"></Attribute> Attribute with semantics
<Attribute ref="device:accuracy"></Attribute> from the model
<Attribute ref="device:frequencyResponse"></Attribute>
<Attribute ref="device:lowerRange"></Attribute>
<Attribute ref="device:resolution"></Attribute>
<Attribute ref="device:upperRange"></Attribute>
<Attribute ref="sysml:io_device" type="xs:string"></Attribute>
<Attribute ref="sysml:sharedSensor" type="xs:boolean" use="required"></Attribute>
<Attribute ref="sysml:tolerancePressureMax" type="xs:float" use="required"></Attribute>
<Attribute ref="sysml:tolerancePressureMin" type="xs:float" use="required"></Attribute>
<Attribute ref="sysml:toleranceTemperatureMax" type="xs:float” use="required"></Attribute>
<Attribute ref="sysml:toleranceTemperatureMin" type="xs:float" use="required"></Attribute>
<Attribute ref="sysml:toleranceVibrationMax" type="xs:float" use="required"></Attribute>
<ReferenceElement name="measures" minOccurs="1" maxOccurs="1"
type="sysml:ParameterType"></ReferenceElement> Specification of a
</ObjectType> Reference Element

2/9/2010 INCOSE Feb 2010 MBSE Workshop 37

 Example: XSD for Sensor Specification
The Sensor becomes
<xs:complexType xmlns="system" name="SensorType">
<xs:annotation> an XSD Complex Type
<xs:documentation>An Object Type</xs:documentation>
</xs:annotation>
<xs:complexContent> Sensor extends Device
<xs:extension base="sysml:DeviceType">
<xs:sequence>
<xs:element name="measures" minOccurs="1" maxOccurs="1">
<xs:annotation>
Sensor
<xs:documentation>Reference Element. Attribute nc:ref is used to point to the referenced value, which must be of type ‘measures’
sysml:ParameterType</xs:documentation>
</xs:annotation> Parameter
<xs:complexType>
<xs:annotation><xs:documentation>A Reference Element Type</xs:documentation>
</xs:annotation>
<xs:attributeGroup ref="nc:W3C-AttributeGroup"/>
<xs:attributeGroup ref="nc:NC-AttributeGroup"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute ref="data:bitsPerSample">
<xs:annotation>
<xs:documentation>An Attribute. <xs:annotation>
<xs:documentation>Value of this attribute should be of type xs:int</xs:documentation>
</xs:annotation>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute ref="data:bitsPerSecond">
<xs:annotation>
Attribute definition
<xs:documentation>An Attribute. <xs:annotation>
<xs:documentation>Value of this attribute should be of type xs:int</xs:documentation>
</xs:annotation>
</xs:documentation>
</xs:annotation>
</xs:attribute>
…

2/9/2010 INCOSE Feb 2010 MBSE Workshop 38

 NASA Modeling and Simulation - tools can
interoperate through the use of OWL-compliant XML
schemas and controlled vocabularies

Community Of Practice - 2
Community Of Practice - 1
Subsystem Team 4
Subsystem Team 3
Subsystem Team 2
Subsystem Team 1

Developer Developer Developer Developer

Domain Specific Tool Performance Tool Risk Tool Cost Tool
Tool 1 Tool 2 Tool 3 Tool 4
inputs outputs inputs outputs inputs outputs inputs outputs
• Assumptions • Assumptions • Assumptions • Assumptions
• Caveats • Caveats • Caveats • Caveats
• V&V • V&V • V&V • V&V
Horizontal Integration among Capabilities within each Subsystem

Shared Vocabularies and Semantics Analyst

Decision Support Tool
Analyst Trades
inputs Support Tool outputs
Decision
• Assumptions
Trades
• FOMs
inputs outputs
• Budget
• Assumptions
• FOMs
• Budget

Aggregate
Results

2/9/2010 INCOSE Feb 2010 MBSE Workshop 39

 How can ontologies be put to work?

• Model-Based Specifications
– Schemas and Controlled Vocabularies
• Data Interoperability
• Generative Documentation
• Registries
• Metadata Management
• Semantic SOA
• Ontology-Driven Systems
• Second Generation SysML tooling
2/9/2010 INCOSE Feb 2010 MBSE Workshop 40
 Concluding Remarks
• Ontologies can be used for specifications as well as
inferencing
• Ontology Architecture and Namespace management are
key to success
• OWL + Rules (SPIN) provides expressive support for
knowledge modeling, transformations and documentation
• OWL can interoperate using XML technologies through the
use of XML SchemaPlus and controlled vocabularies
• Data Quality requires compliance to Naming and Identifier
Rules
• Other presentations at http://www.scribd.com/ralphtq

2/9/2010 INCOSE Feb 2010 MBSE Workshop 41

 Thank You

Ralph Hodgson
E-mail: rhodgson at topquadrant.com,
Ralph.Hodgson at nasa.gov
http://twitter.com/ralphtq
http://www.scribd.com/ralphtq

2/9/2010 INCOSE Feb 2010 MBSE Workshop 42

 Backup

2/9/2010 INCOSE Feb 2010 MBSE Workshop 43

 Semantic XML and XMI Transformers

2/9/2010 INCOSE Feb 2010 MBSE Workshop 44

 Semantic XML:
OWL representation of XML document
• XML can be modeled in OWL as a Composite Pattern
• Elements contain Elements
composite:child relations
• Elements have attributes
UBL CreditNote

2/9/2010 INCOSE Feb 2010 MBSE Workshop 45

 Importing XMI.XSD file into TopBraid
Composer provided the start for XMI Ontology

2/9/2010 INCOSE Feb 2010 MBSE Workshop 46

 Ontology Architecture for SysMO Model
Creation
SysML Metamodel in XMI
SPIN Inferencing

Semantic XML

Composite Pattern

SPIN SPARQL Syntax

2/9/2010 INCOSE Feb 2010 MBSE Workshop 47

 Semantic XML translation of SysML
using TopBraid Composer

2/9/2010 INCOSE Feb 2010 MBSE Workshop 48

 SPIN – using SPARQL as a Rules
Language
• SPIN – SPARQL Inferencing Notation
– A Rules Language based on SPARQL
– define constraints and inference rules on Semantic Web models
– http://spinrdf.org
• Specification for representing SPARQL with RDF
– RDF syntax for SPARQL queries
• Modeling vocabulary
– constraints, constructors, rules
– templates, functions
• Standard Modules Library
– small set of frequently
needed SPARQL queries
more at www.spinRDF.org

2/9/2010 INCOSE Feb 2010 MBSE Workshop 49

 SPIN Example: Kennedy Family Rules –
Using SPARQL as a Rules Language
Person Class

SPIN Rule using

SPARQL Construct

2/9/2010 INCOSE Feb 2010 MBSE Workshop 50

 SPIN Example: Kennedy Family Rules
(Template Version)
Template for Rule

Class invokes rules

by passing arguments
to templates

2/9/2010 INCOSE Feb 2010 MBSE Workshop 51

 Example of a NExIOM SPIN Rule for
XML Generation from NASA Ontologies
CONSTRUCT {
?genlib_rootType sxml:element ?genlib_rootElement .
?genlib_xmlnsType a owl:DatatypeProperty .
?genlib_xmlnsType sxml:attribute ?genlib_rootTypeAttr .
?genlib_root ?genlib_xmlnsType ?genlib_baseURI .
?genlib_root genxml:xsiSchemaLocation ?genlib_location . }
WHERE {
?genlib_root a ?genlib_rootType .
?genlib_rootElement tops:constructString ( "{0}:NExIOM" ?genlib_nsQName ) .
?genlib_rootTypeAttr tops:constructString ( "xmlns:{0}" ?genlib_nsQName ) .
LET (?genlib_xmlnsType := smf:buildURI("{?genlib_nsQName}:baseNSAttribute")) .
?genlib_locationSimple tops:constructString ( "{0} ../NExIOM_XSP_XSD-{1}"
?genlib_baseURI ?genlib_nsQName ) .
?genlib_locationNoNumber tops:constructString ( "{0}.xsd" ?genlib_locationSimple ) .
OPTIONAL {
FILTER (?genlib_revisionNumber != "0") .
?genlib_locationNumber tops:constructString ( "{0}-(v{1}).xsd" ?genlib_locationSimple
?genlib_revisionNumber ) . } .
LET (?genlib_location := smf:if((!bound(?genlib_locationNumber)),
?genlib_locationNoNumber, ?genlib_locationNumber)) .
}

2/9/2010 INCOSE Feb 2010 MBSE Workshop 52

 Ends

2/9/2010 INCOSE Feb 2010 MBSE Workshop 53