The Web Ontology Language (OWL) and the Semantic Application Design Language (SADL)

Last revised 07/03/2017. Send comments to

Table of Contents

The Web Ontology Language (OWL)

Last revised 07/03/2017. Send comments to

The Web Ontology Language (OWL) is a recommendation of the W3C. It supports all the foundational concept identified above.

Properties which are not specified as object properties or data type properties are called RDF properties. (RDF stands for Resource Description Framework and is a W3C “standard”; rdf:Property is actually the super class of owl:ObjectProperty and owl:DatatypeProperty.) In general, it is a good idea to define properties that are used as being either object properties or data types properties instead of using RDF properties as that provides additional information. OWL also defines owl:AnnotationProperty. Annotation properties are meant to provide additional information not of a logical nature and which will be ignored by reasoners. In OWL 1 annotation properties cannot be given domain and range.

In addition, OWL supports the importing of one model into another using the owl:imports property. The subject of an import statement is the URI identifying the importing model. The object (value) of the property is the URI of the model being imported. All of the concepts in any imported model, directly or indirectly imported, are available for use in the importing model. This is illustrated in the next section by the import statement on line 2 of the example.

Defining Classes, Properties, and Individuals in SADL

The Semantic Application Design Language (SADL) is a controlled-English grammar and a supporting integrated development environment (IDE) for creating OWL models (along with other constructs discussed latter). The current version of SADL is Version 3 and has the expressivity of and maps directly to OWL Version 1 plus qualified cardinality from OWL Version 2. All our examples in this section will be expressed in SADL syntax.

To provide a grounding example, we take the challenge problem of a steam boiler system. Following are some classes that begin to define a formal model of this domain.

Note that this model has a URI identifier given on line 1 as well as the prefix boiler, referred to as “alias”. As noted above in the discussion of XML namespaces, all of the concepts defined in this model are in this namespace. So, for example, the full identifier of SteamBoilerSystem is In any context which has the same prefix to namespace URI mapping, it can also be referred to by the qualified name boiler:SteamBoilerSystem.

Note that on line 4 SteamBoilerSystem is declared to be a sub-class of System. System is defined in the basic model which is imported on line 2. This model is shown below.

The parenthetical “note” on lines 2 and 6 are SADL’s way of adding the owl:AnnotationProperty rdfs:comment to a concept, the overall model in line 2 and the component property in line 6. Observe also that Failed is given an “alias” on line 11. This translates in the OWL to the annotation property rdfs:label. Any concept being defined may be given as many “notes” and “aliases” as desired. Note that the alias (rdfs:label) cannot be directly used instead of the concept name, but it can be retrieved by queries and other constructs by explicitly identifying that the rdfs:label of the concept is to be used.

As can be seen in the example above, the SADL IDE uses different colors and fonts for different kinds of model concepts. Class names are dark blue bold, individuals are light blue, object and data type properties are green bold. While there is no enforcement, OWL modeling convention is to use upper case starting letters for class and individual names and to use lower case starting letters for property names.

Further Definition of Classes Using Property Restrictions

There are two ways of defining a class. One way is to specify all the individuals that belong to the class. In other words, the class is the specified set of members and there are no other members of the class. For example,

Season is a class, can only be one of {Spring, Summer, Fall, Winter}.

Obviously, this approach will not work in many cases as the members cannot be enumerated. The other way to define a class is to specify the properties and possibly the property values that members of the class must have or not have. Axioms in the model that do this are called property restrictions. There are several types of property restrictions.

  1. Cardinality restrictions identify the number of values for a given property that a member of the class can/must have
    1. Exact cardinality – a member of the class must have exactly the specified number of values for the given property
      wheel of Bicycle has exactly 2 values.

    2. Minimum cardinality—a member of the class must have at least the specified number of values for the given property but can have more
      child of Parent has at least 1 value.

    3. Maximum cardinality—a member of the class can at most have the specified number of values for the given property but can have fewer
      primaryResidence of Person has at most 1 value.

  2. Qualified cardinality restrictions identify the number of values of a specified type for a given property that a member of the class can/must have
    1. Exact qualified cardinality – a member of the class must have exactly the specified number of values of the specified type for the given property; it can have other values of the property of other types
      part of Bicycle has exactly 2 values of type Wheel.

    2. Minimum qualified cardinality—a member of the class must have at least the specified number of values of the specified type for the given property but can have more; it can have other values of the property of other types
    3. Maximum qualified cardinality—a member of the class can at most have the specified number of values of the specified type for the given property but can have fewer; it can have other values of the property of other types
  3. Some values from restrictions specify that a member of a class must have some values (at least one) of a specified type for a given property; it can have values of other types for the property unless otherwise restricted
  4. All values from restrictions specify that, for a member of the given class, all the values of a given property must be of a given type; it cannot have values of the property of any other type, but it does not require that there be any values
  5. Has value restrictions specify that a member of a class must have the specified value for the specified property; it can have other values as well, unless otherwise restricted
Property restrictions allow us to refine our steam boiler model. Qualified cardinality restrictions on lines 13 through 16 and 19 through 20 allow us to constrain how the equipment is configured to create a SteamBoilerSystem. Such a system has exactly one SteamBoiler and at least 1 Pump and PumpController. Each Pump is controlled by exactly one PumpController. The SteamBoiler has exactly one WaterLevelDetector and one SteamFlowDetector.

Equivalent Classes, Also Known as Necessary and Sufficient Conditions

The property restrictions introduced in the previous section allow a model builder to specify necessary conditions for an individual to be a member of a class. It is possible to express a stronger axiom stating that a set of conditions is not only necessary for an individual to be a member of a class, but they are sufficient conditions, meaning that if the conditions are met the individual can be inferred to be a member of the class. While in logic one might expect necessary and sufficient conditions to be expressed as “if and only if”, in SADL the expression is just “only if”. In terms of propositional logic, for the propositions p and q, we have the following:

1.       p → q (read p implies q, example: [X is a member of class Man] implies [X has property gender with value Male], a has value restriction)

2.       p ↔q (read p if and only if q, example: [X is a member of class Parent] if and only if [X has at least one value of child property], a minimum cardinality restriction)

**** Examples, discussion ****

XSD and User-Defined Data Types

The possible ranges of an OWL data type property are the set of XML Schema Definition (XSD) data types and their derivatives. The SADL keywords corresponding to the XSD data types are the following.

anyURI double gYearMonth nonPositiveInteger
base64Binary duration hexBinary positiveInteger
boolean float int string
byte gDay integer time
date gMonth long unsignedByte
dateTime gMonthDay negativeInteger unsignedInt
decimal gYear nonNegativeInteger  

The most common use of these XSD data types is in specifying the range of an OWL data type property.

age describes PhysicalThing with values of type decimal.

But what if we would like to have a more restricted range? Say decimal number greater than or equal to 12 and less than 18 as a property restriction of age on the Adolescent class? We accomplish this with user-defined data types. A user-defined data type is like a subclass of an XSD data type or of a union of XSD data types. The SADL grammar is like sub-classing except that the restriction is expressed as facets. The general syntax is as follows.

<user-defined-datatype-name> is a type of <xsd-data-type(s)> <facets>

Here are some examples.

adolescentAge is a type of decimal [12.0, 18.0).           // decimal number >= 12 and < 18
clothingSize is a type of {int or string}.                        // either an int or a string
is a type of string {"short", "medium", "tall"}. // enumeration of 3 possible string values for height
is a type of string "[0-9]{3}-[0-9]{2}-[0-9]{4}".        // here the facet is a regular expression that matches valid Social Security Numbers
is a type of int length 4 .
is a type of string length 1-4 .

Once a user-defined data type has been defined, it can be used as a property range or in a property restriction.

age of Adolescent only has values of type adolescentAge.

Note that user-defined data types are blue like classes but not bold. User-defined data types are translated to RDFS Datatypes in the OWL model.

SPARQL and the SADL Query Language

SPARQL is a W3C recommendation and a powerful graph query language for finding information in a graph-based ontology model. While SPARQL is very powerful, it is also complex. SADL supports writing relatively simple queries in the SADL Query Language, which has the same syntax and coloring as the rest of SADL. The SADL Query Language translates to SPARQL behind the scenes. SADL also supports expressing queries directly in SPARQL, although then the query is not validated for syntax and correct reference to model concepts until it is executed.

A query in SADL is preceded by the Ask keyword, which is followed by an optional query name and then a colon. This is followed either by a SPARQL query as a quoted string or a SADL query. Below is an example of each.

Ask: select distinct m, agent, sc
where m is a Knowledge and m has usability ku and ku has user agent and ku has score sc
order by desc sc.

Ask: "select ?m ?agent ?sc
where {?m <rdf:type> <Knowledge> .
OPTIONAL {?m <usability> ?ku .
?ku <user> ?agnt .
?ku <score> ?sc}}
order by desc(?sc)".

The first query, in SADL syntax, shows variables in pink bold and makes it easy to identify the properties and classes involved. The second query shows a little bit of the greatly larger expressivity of SPARQL. In the latter all but the first triple pattern is optional, meaning that a match to the first pattern will be returned even if the additional patterns are not matched.

Anatomy of a SADL Project

The OwlModels Folder

Models created or edited in SADL are saved in multiple formats. The actual SADL model is saved in a text format as a .sadl file and is normally opened in the SADL Xtext editor, which provides semantic coloring, hyperlinking, etc. This model file is sequential in nature and lends itself well to comparison between versions. It should be placed under version control. In addition, if the model is valid so that it can be translated to OWL, the file is saved as an OWL file in the OwlModels folder. The OWL file is used by the model processors to do semantic tasks such as validation of imported models. The OWL model should not be edited as it is frequently regenerated from the .sadl file. The base filename of the OWL file is the base file name of the .sadl file. The exact syntax of the OWL file, and therefore the file extension, is controlled by a preference and can be any one of

The SADL IDE architecture requires reasoner/translator pairs to accomplish functions beyond model editing. The default reasoner is the Jena reasoner and it has an associated Jena translator. This translator does not do anything to the OWL model as the reasoner can read in OWL directly. It saves rules to a .rules file in Jena rule syntax. It saves equations to a .pl Prolog file. These files also have the same base filename as the .sadl file. Other reasoners may require that the OWL file and any other constructs be in other formats and it is the job of the associated translator to generate the necessary input format for the reasoner.

Implicit Models

SADL 3 has some built-in concepts that are deemed to be widely useful, which will be elaborated in SADL Constructs Useful in Building Models. Rather than having to explicitly import the models for these concepts, the models are imported into SADL models implicitly. Some of these implicit models are present as OWL models automatically created in the OwlModels folder. These models have content that a modeler would not normally need to see to use the built-in concept. Others models are automatically created as .sadl files placed in a project folder named ImplicitModel. It is anticipated that modelers will want to be able to easily view and in some cases even edit the content of these implicit models.

The SADL 3 implicit models, with folder identified, are as follows.

The Temp Folder

The project’s Temp folder can be used for various purposes. One subfolder of potential interest is the ErrorDocs folder which contains the file SadlErrors.html. This file contains a table of all the SADL IDE errors along with their descriptions. Derivative grammars may also provide their own error tables and other output.

Another subfolder is Logs, in which metrics reports are placed. Metrics reports capture information about the project as a whole.

The Graphs Folder: An OWL Ontology is a Graph

All elements of an OWL model can be expressed as a statement with a subject, a predicate, and an object or value. Such a statement is called a triple. Such a statement also constitutes one segment of a directed graph: node->edge->node. Since an OWL model is a collection of such statements, it is also a mathematical directed graph. This means that graph-theoretic methodologies can be applied to OWL models. An example is the use of graph query languages such as SPARQL to retrieve information from an OWL model.

Such a model can also be visualized as a graph. Two kinds of ontology graphs can be generated in the SADL IDE. One can create a graph of an entire ontology file. This is done by selecting a .sadl or .owl file in the Eclipse Project Explorer and activating “Graph Ontology” on the SADL menu. The default visualizer uses GraphViz and generates .svg files. To enable the default GraphViz visualizer, download and install GraphViz. Then set the environment variable GRAPHVIZPATH to the absolute file system location of the installed GraphViz "bin" directory. If the .svg graphics file extension is associated with a browser, the generated file will be opened automatically. Subject to browser support, .svg graphic files may be searched by text matching, making it much easier to find nodes and edges in the graph.

Alternatively, one can select the project and “Graph Ontology” command will create a graph (.svg file) of each of the .sadl and independent .owl files in the Eclipse project and also generate a graph of the project's imports of one model by another. In that case, it is this imports graph which will be opened automatically if the .svg file association exists. In either case, each external reference in a graph is a link to the .svg file containing the resource, which can be opened in the browser by clicking on the node. Graphing our steam boiler project as an example, here is the imports graph.

Note that namespace prefixes are used to label nodes in the graph. The only explicit import is that of the basic model by the boiler model. Each node in the graph is a hyperlink to the graph of that model. Clicking on basic displays its graph.

Likewise, clicking on boiler displays its graph.

The Graphs subfolder of a project contains all of the graph files that have been generated. These files are given names indicative of their content and can be opened directly. Note that the contents of the folder may need to be refreshed before all results are visible in Eclipse. Note also that SADL models with errors will not generate OWL files and therefore will not generate graphs as the graph is a rendition of the OWL file model.