DLG²- A Graphical Presentation Language for RDF and OWL

This first version of document is now considered outdated. The DLG² language has been redesigned. The RDF-G and OWL-G packages described in this document are now separated from the core package of DLG². The core package is assigned a new permanant URI of "http://www.charlestoncore.org/dlg2/". Package RDF-G is assigned a URI of "http://www.charlestoncore.org/dlg2/rdf" and package OWL-G is assigned a URI of "http://www.charlestoncore.org/dlg2/owl/". Please visit the respective URI for specification document..

Motivation

The purpose of this document is to provide a formal description of a graphically-based language that can be used to simplify the presentation of RDF (Resource Description Framework) models. Please note the language is designed mainly for human but not for machine consumption. This may sound ironic because: if it were not for machine processing, there perhaps won't be RDF at the first place. But, as I have always thought: the name of machine interoperability is a deceptive one because what it meant is the human interoperability but through machine. Hence, no matter what kind of communication technology we intended to use, the ultimate goal is to help human to communicate easily and efficiently.

There are many circumstances where RDF is discussed without needing it to be understood by machine. When writing a tutorial or presenting in a meeting, for instance, we only needed to convey our intentions to other humans. Under such circumstances, a picture is always worth a thousand words. In particular, semantic web envisions machine interoperability through shared ontologies, where the design, promotion, adoption and implementation are mostly human activities. A human-friendly RDF language is obviously helpful under these circumstances.

Think it in this way: RDF itself is a conceptual model. To make machine understand better, the model needs to be serialized (computers only take message in serial fashions) in languages like RDF/XML, N3 and N-Triple etc. To make human understand better, the model needs to be graphicalized (I suppose human takes graphics better, but I could be wrong) in languages like the presenting one.

About the name

A language needs a name, just like a resource needs an URI Reference. I have thought a few names but end up using DLG² for the following reasons.

First, the language is designed to describe a directed labeled graph so that "DLG" serves the purpose. Second, the language is supposed to be about RDF, which is a form of DLG but not itself RDF. Therefore, "DLG²" (pronounces DLG too) makes more sense than "DLG" alone. Third, DLG can also be an acronym for Defined Language for Graph, which hopefully will make sense to you after you finish reading this text.

Why not UML?

Most of you must have asked this question: why don't you extend the language from Unified Modeling Language (UML). I guess many of you have tried, just like I did, and I hope those of you who have tried have felt the same as I did: UML just didn't work very well for RDF. The open world assumption of RDF brings "properties" to the same level as "classes". This essentially breaks the foundation of the UML's class diagram. In addition, many RDF axioms need special notations that just couldn't be easily expressed with UML.

Basic Principle

The founding principle of DLG² is simple: to substitute complicated graph with simplified ones.

The idea of substitution is not a new one. It in fact has been practiced in many programming languages. For instance, C language uses "define" directive and XML uses namespace declaration to replace verbose text with concise ones . There seems no reason that we can't apply the same principle to graphic notations. For example, why can't we use a simple arrow line to replace an explicitly labeled one for rdf:type and a rectangle to represent an instance of a Class (see Figure 1-1 ) ?

Figure 1-1: Examples of using the define directive to simply graphic notation

In fact, this kind of "macro" concept is the founding principle of DLG². By gradually introducing new graphic notations with definitions, we can use a more concise but comprehensive graph to represent the verbose one. But to use the C-formalism shown in Figure 1-1 doesn't suit the graphical language very well because there is just too much space in a graph to adopt the "space delimited" concept. Therefore, in DLG² we will use an identical sign ≡ to indicate that two graphs are substitutable for each other. More details will be introduced in later section.

Infrastructure

DLG² consists of two essential packages: (1) The DLG package contains the primitive notations for constructing a directed labeled graph and (2) The Extension package contains syntactic notations, which can be used to extend language vocabulary. ( Figure 1-2 )

Figure 1-2 The DLG package

In addition to this core, this document also defined two extension languages. The first one is called RDF-G. It is designed to express concepts introduced in basic RDF and RDF schema language. The second one is called OWL-G. It is designed for vocabularies defined in Ontology Web Language (OWL). The dependences of RDF-G, OWL-G and the core package of DLG² are shown in Figure 1-3 .

Figure 1-3 - Relationship between the Core language and RDF-G and OWL-G

Extension Package

The extension package contains three notations (see Figure 2-1 ).

Figure 2-1: The Extension package

With these three notations, DLG ² can be extended both (1) graphically with substitution definitions by introducing new graphical notation and (2) textually with text based serialization language.

Substitution sign

Notation

The substitution sign is denoted as an identical sign (see Figure 2-1 ).

Semantics

A substitution sign suggests that two graphs on each side of the identical sign are interchangeable.

Example

Let's work through a simple example shown Figure 2-2 . In the example, a node is shown as an ellipse and an arrow line is as the arc. In Figure 2-2 , the graph on the left contains an edge "ex:p" connecting from node "x" to node "y". The rule shown in the figure defines that an arc labeled with "ex:p" can be replaced with a different type of line without label. The line pattern used to denote the "ex:p" arc has one end labeled with an open circle to indicate the direction of arc. In addition, the receiving node of arc "ex:p" can be replaced with a labeled diamond.

Figure 2-2: Example usage of using substitution sign

Because identity sign is symmetric, it also implies that the graph on the right can also be replaced with the graph on the left. Hence, with carefully defined substitution rules, we can introduce new symbolic notation to make a directed labeled graph more concise, or we can reverse a graph back to its original form.

Conventions

Because DLG² is designed to represent RDF and OWL, we assume readers have the basic familiarity with the technology. The general conventions used in DLG² are:

1. Any label without a namespace is considered as a variable. For instance, in the above example, any node at the receiving end of arc "ex:p" will be replaced with a diamond of the same label.

2. Any label with a namespace is considered part of the graph. For instance, only the "ex:p" arc can be replaced with a non-labeled ring-ended line. Any other types of arcs do not apply.

Text pad

Under many circumstances, for instance, to enter a list of numbers of the literal values, it is much easier to use a text based representation than drawing graphs. Furthermore, we often also need to use prefix, such as namespace URI, to simplify the text presentation. When such need occurs,

Notation

A text pad is shown as a rectangle shape with a triangle embedded at the bottom right corner ( Figure 2-1 ). The text string within the text pad is in a particular RDF serialization language. For the purpose of expressing RDF, the default language is N3. If any other text based serialization language than N3 is used, the name of the language should be displaced in braces ({ }) at the very beginning of the string.

Example

For instance, Figure 2-3 defines the default namespace used throughout DLG².

Figure 2-3: Namespace prefix defined with a text pad.

Or, the same content is described by fragment of RDF/XML,

Figure 2-4: Namespace prefix defined in RDF/XML.

Predefined namespace prefix

The namespace prefix is the defined implicitly. In other words, any DLG² extension implies the definition of these namespace prefix.

Two additional prefix shall be defined but haven't yet.

Graphic pad

The graphic pad is used to introduce new graphic notations via the substitution rules writing inside.

Notation

Graphic pad is shown as a file folder symbol. It is composed with a rectangle shape with a trapezia tab (see Figure 2- 5 ). The tab is used to enter the URI of the definitions. The rectangle is used to place the substitution definitions.

Figure 2-5: Notation for graphic pad

Default definitions

Language defined in this document - DLG, RDF-G and OWL-G is implicitly included. No graphic pad is needed to be present to indicate the use of notations defined in that two language.

DLG Package

The conceptual model of RDF is a directed labeled graph. Many existing documents and tutorials employed a convention where a resource is represented as an ellipse, an arrow-headed line as a property and a plain rectangle as literals (see Figure 2-6 ). We intend to keep this convention so that we designated these three symbols as the primitive symbols that make up the DLG package.

Figure 2-6: Existing conventions to draw a DLG

Resource Ellipse

Notation

By definition, anything with an URIRef will is a resource. Graphically, a resource is expressed as an ellipse with URIRef placed inside.

If the URIRef is omitted, it indicates the resource is a blank node, which is also called anonymous resource according to RDF-MS. Occasionally, if a user want to label a blank node with a temporary ID, i.e., it shall be placed within the double quotation mark (see Figure 2-7).

Figure 2-7: Notation for a resource

Rationale

The reason we use double quotation mark for nodeID is because this symbol is prohibited for use in URI according to RDF2396.

2.2.2 Property Line

Notation

A property is shown as an arrow with a solid triangle arrowhead connecting from the subject to the object of a RDF statement, where the arrow head must be connected with the object resource. The URIRef of the property is shown near the property line (see Figure 2-8).

Figure 2-8: Notation of a property line

Literal Box

Notation

A literal is shown as a solid outlined rectangle. The value of the literal is placed inside of the rectangle. A rectangle can only be used as the object of a statement, i.e., they can only be connected to the point end of property line. The literal value follows the syntax of notation 3 so that they can be used easily to show a typed literal. Figure 2-9 shows an example from section 2.4 of RDF Primer [1].

Figure 2-9: Notation for literal

2.2.4 Extension with Text Pad

Sometimes it is convenient to shorthand graph with text based language. So the generic rule is to extend graph with a text pad is defined as shown in Figure 2-10.

Figure 2-10: Extension with text pad in DLG

What it meant is that a text pad can be attached to any resource via a solid line or attach the text pad directly to the bottom of the resource notation. The subject of text description should be implicitly the resource in question.

RDF-G is designed to simplify the graphical presentation of a directed labeled graph with vocabularies build in RDF and RDFS. Because the purpose of this documentation is to define the graphic notation for the RDF vocabulary, the precise semantics will not be elaborated unless otherwise specified.

3.1 The rdf:type

RDF-G Definition 1: Type symbol.

Notation

An rdf:type property is simplified as arrow with an open arrow head without any text label.

Note the difference of the pointed ends between the labeled edge and unlabeled type symbol.

Rationale

The difference of the arrow head between the property symbol and the type symbol is not very obvious. I opt to use an arrow instead of other shape, such as a square or a diamond etc., is because of its simplicity. Also, under most circumstances, a rdf:type always points to a class definition. The relationship will be self-evident for its type.

3.2 The rdfs:Class

RDF-G Definition 2: Class symbol.

Notation

An instance of an rdfs:Class is shown as a rectangle with double-line border. The URIRef of the entity shall be placed inside the rectangle.

Presentation Options

There are other class notations that will be discussed in later section (see section 3.5).

Property

RDF-G Definition 3: Property symbol

Notation

A property is shown as a wedge shape (see RDF-G Definition 3). The sharp side is called its range side and the rest sides are called the domain sides (see the Figure 3-1). The value of rdfs:domain must be connected to the domain sides and the value of rdfs:range must be connected to the range side. By definition, the value of both rdfs:domain and rdfs:range must be an rdfs:Class and it is illegal in RDF to allow an rdf:Property to have property. Thus, if other description needed to be made about the property, it will be self-obvious.

Figure 3-1: Property symbol.

Example

Figure 3-1 shows an example of how to use the property symbol. For example, the following example from RDF Primer

ex:hasMother rdfs:range ex:Female. ex:hasMother rdfs:range ex:Person.

states that the property ex:hasMother has domain of ex:Person and its range is the "intersection" of ex:Female and ex:Person. (Note, the intersection mentioned in last sentence is according to the default semantics of RDF). The above textual description can be shown as the following graphics with an additional comments added by ours.)

Example 3-1: An example of using property symbol

Presentation Option

There are other property notations that will be discussed in later section (see section 3.5).

3.4 Individual

In OWL-Lite and OWL-DL world, the universe of discourse for owl:Class is distinct from that of individual. The concept of an individual is needed even though there is no vocabulary defined for the purpose in RDF.

RDF-G Definition 4: Individual symbol

Notation

An individual is represented as a two compartmented solid outlined rectangle with round corners. The top compartment is for placing the URIRef; the second compartment, which is mandatory in order to avoid confusion with the shape of ellipse, is used to enter the type information. If the type compartment is empty, it is assumed to be an instance of rdfs:Resource. (See Figure 3-2)

Figure 3-2: Individual Symbol.

3.5 Generalization

The concept of generalization is familar to those who are familar with the object oriented technology. The concept of rdfs:subClassOf in RDF and that in UML (Unified Modelling Language) are isomorphic. Hence, we will use the same symbol.

RDF-G Definition 5: Generalization symbol for rdfs:subClassOf

RDF-G Definition 6: Generalization symbol for rdfs:subPropertyOf

Notation - 1

The generalization symbol is shown as a line with one end empty and the other with an emptied triangle arrow head. The symbol is used to indicate both rdfs:subClassOf and rdfs:subPropertyOf. The empty end always connected to the entity being subsumed whereas the arrow head connects to the entity that subsumes.

Examples

The figure 18 of the RDF Primer can be simplified in DLG² as shown in example 3-2

Example 3-2: A vehicle class hierarchy

Notation 2

In addition, type information can also be shorthanded to place within a pair of angle braces in the second compartment. Please note the different shape of the second compartment between a Class and a Property. It is designed in such to make consistent use of symbol. Think it in this way, the notation of the second compartment is still a Class and a Property, respectively. Therefore, the plain string should be the URIRef of a property as well. The type information however must be treated differently. Angle bracket is used because it is conventionally used to note the datatype.

RDF-G Definition 7: Alternative Class notation

RDF-G Definition 8: Alternative property

For instance, the following example described in RDF Primer,

ex:Van rdfs:subClassOf ex:MotorVehicle.

can be easily shown as:

Example 3-3: Simple generalization

Presentation options

Note the rule defined in section 2.2.4 always applies. A note pad can be attached to the Class symbol for text based description in N3. The definition of rdfs:Class itself can be shown in Figure 3-3.

Figure 3-3: Definition of rdfs:Class.

Note the difference between these representations. The first two are intended to express the subsume relation whereas the last one for type information.

3.6 Reification

RDF-G Definition 9: Reification

Notation

An RDF Reification is shown by connecting an rdf:Statement to the object of rdfs:predicate with a arrow shaft with the vanes end connected to the statement resource (see RDF-G Definition 9). Please note the object of rdf:subject, rdf:predicate and rdf:object are labeled with dashed outline instead of the usual solid lines. The reason for this design is because RDF has no way to associate a reification statement to an instance of a triple in an RDF document (See RDF-P section 4.3). Therefore, it is possible that an rdf:Statement is made to say s-p-o while there is an assertion for the same statement. In the later case, we need to make the statement related resource's outline solid to indicate the difference.

Rationale

The introduced notation doesn't seem to simplify the presentation to a great extent. But the semantics is now much more obvious than the original notation. Also, by following the same convention as the s-p-o triple, all user-customized notation can also be used as part of reification. For instance, a reification statement of the follow:

ex:triple1 rdf:type rdf:Statement

ex:triple1 rdf:subject ex:Truck

ex:triple1 rdf:predicate rdf:type

ex:triple1 rdf:object rdfs:Class

can be denoted graphically as shown in Example 3-4.

Example 3-4: Example reification

3.7 Structured value

RDF-G Definition 10: Structured data with rdf:value

As discussed in RDF-P section 4.3, there are often needs to describe structured data with a main value which is often labeled with an rdf:value. However, under most circumstances we don't want to assign a URI to an annoymous entity which sole purpose is to create an association. Hence, in RDF/XML a syntax of rdf:parseType="Resource can be used as an attribute to shorthand the description. Here we also devised a shorthand notation by using an ellipse divided in half (see RDF-G Definition 10 ). The left half is used to write the literal value with proper datatype. The right half is used to write other property value such as "unit" etc. To indicate the property type, we follow the same convention as N3, so the property is indicated by "^" to indicate a backward traversal.

Examples

The following example is from example 21 of RDF primer

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:exterms="http://www.example.org/terms/">
  <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
    <exterms:weight rdf:parseType="Resource">
      <rdf:value rdf:datatype="&xsd;decimal">2.4</rdf:value>
      <exterms:units rdf:resource="http://www.example.org/units/kilograms"/>
    </exterms:weight>
>  </rdf:Description> </rdf:RDF>

can be described as shown in Example 3-5

Example 3-5: Structured value

3.8 List symbols

List is an often used construct with avery verbose presentation syntax. It is therefore very necessary to define a short hand for it.

RDF-G Definition 11: List symbol

RDF-G Definition 12

Notation

An instance of rdf:List is represented as the combination of a rectangle with a square (See RDF-G Definition 11). The rectangle is used to enter the URIRef of this list and the square is used to put some arbitrary number as a label. The list elements are connected with an arrowed line with arrow place in the middle, but not at the end of line.

An alternative presentation is to draw lines directly from list to its member. But since rdf:List is by default an ordered list, we therefore must label the order of element. The convention employed in RDF-G is to label the lines with sequential number starting from 1.

Presentation Options

If the author thinks the order of the list is not important, the number can be omitted.

Rationale

The reason to introduce a list label is to avoid confusions when an element is used by more than one list. For instance, without a list label, the example shown in Figure 3-4 will cause confusion regarding the membership of e4 and e5.

Figure 3-4: Hypothetical example that two lists share same resource as members.

3.9 Miscellaneous

3.9.1 rdfs:label

RDF-G Definition 13: Label

Notation

The value of rdfs:lable is included in the URIRef compartment and placed behind the URIRef within parenthesis.

3.9.2 rdfs:comments

RDF-G Definition 14: Comments

Notation

The notation of an RDF comment is the same as UML's comments. It is placed within a note symbol and connected to the resource via a dashed line.

When describing the OWL-G, we will follow the general organization of Ontology Web Language Reference (OWLR) [2] and gradually introduce the definition rule.

4.1 Classes

4.1.1 Class Descriptions

4.1.1.1 Class Identifier

OWL-G Definition 1: Class symbols for owl:Class

Notation

The owl:Class is represented similarly to rdfs:Class. The difference is (1) the border is single lined and (2) the second compartment is mandatory. As usual, the top compartment is for URIRef. The second compartment is used the for type information. Its default value is owl:Class, which is optional.

4.1.1.2 Enumeration

OWL-G Definition 2: Enumeration Symbols.

Notation

The Enumeration Class can be simplified according to OWL-G Definition 2.

Rationale

I have considered several alternative designs, such as introducing a new symbol to represent owl:oneOf or attaching the list symbol as the third compartment to the class symbol etc. I choose to omit the type compartment because I think if a class is described through enumeration, rarely will it need a super class. So, I will give it a most simplified representation. If a user has the need to indicate a super class, he/she can still do it by explicitly drawing with a generalization symbol.

The second notation is designed to make it easier to comprehend. Using a logical symbol inside a circle makes it easier to understand.

Presentation options

Remember a text pad can always be attached to a resource. In this case, because the bottom resource is a List, so the subject of the text pad is a list, rather than a Class.

Examples

The example provided in OWLR section 3.1.1 of the following:

<owl:Class>
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#Eurasia"/>
    <owl:Thing rdf:about="#Africa"/>
    <owl:Thing rdf:about="#NorthAmerica"/>
    <owl:Thing rdf:about="#SouthAmerica"/>
    <owl:Thing rdf:about="#Australia"/>
    <owl:Thing rdf:about="#Antarctica"/>
  </owl:oneOf>
</owl:Class>

can be represented in two forms shown in Figure 4-1. (I am not sure if the b figure is correct N3 syntax, but you get the idea).

Figure 4-1: Enumeration Class Example.

4.1.1.3 Property Restrictions

OWL-G Definition 3: Restriction Symbol.

Notation

A restriction is represented as an empty filled triangle connecting between a class and a property.

4.1.1.3.1 Value Restrictions

OWL-G Definition 4: Notation for owl:allValuesFrom

OWL-G Definition 5: Notation for owl:someValuesFrom

OWL-G Definition 6: Notation for owl:hasValue

Notation

The line end for owl:allValuesFrom property is very similar to ?. The line end for owl:someValuesFrom property is very similar to ?. There is no line end for owl:hasValue.

4.1.1.3.2 Cardinality Restrictions

OWL-G Definition 7: Notation for owl:minCardinality

OWL-G Definition 8: Noation for owl:maxCardinarlity

OWL-G Definition 9: Notation for owl:cardinality

Notation

Cardinality constraints is placed within the owl:Restriction symbol. They are typically shown in the format:

m..M

where "m" is the value of owl:minCardinality and "M" is the value of owl:maxCardinality. The asteroid (*) is used as part of the specification to indicate the unlimited upper bound.

Presenation Options

Often in the design of an ontology, we will met situiation where we want to both create a Property and create a restriction at the same time. Such situiation occurs very often if to follow object oriented methodology. To create a short hand for this situiation, the extension symbols can be merged into the property symbol as it is shown in OWL-G defintion 9.1. But such symbol can only be used when it won't create confusion.

OWL-G Definition 9.1: Notation for combining a Property definition and a restriction.

Another situation that is useful when design the "array" type of resource. The native rdf:List can not restrict the type of resource being put in an array but it can be achieved through owl:Restriction. A short hand notation is designed for this purpose.

OWL-G Definition 9.2: Notation for a rdf:List with its containing element type be restricted.

4.1.1.4 Intersection, union and complement

OWL-G Definition 10 Notation for owl:intersectionOf

OWL-G Definition 11 Noation for owl:unionOf

OWL-G Definition 12 Noation for owl:complementOf

Notation

Symbols for owl:intersectionOf and owl:unionOf are the same for owl:someValuesFrom and owl:allValuesFrom. Because they are applied to different entities, they won't cause confusion. The reason we match owl:intersectionOf to owl:someValuesFrom is they sort of shares similar semantics because only "some" of the List members will be a member of the class in question. Similarly, owl:unionOf uses the same symbol of owl:allValuesFrom has both include the all-ish kind of meanings.

Examples

The example show in OWLR 3.1.3.1 of the following:

<owl:Class>
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Tosca" />
        <owl:Thing rdf:about="#Salome" />
      </owl:oneOf>
    </owl:Class>
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Turandot" />
        <owl:Thing rdf:about="#Tosca" />
      </owl:oneOf>
    </owl:Class>
  </owl:intersectionOf>
</owl:Class>

Its OWL-G representation can be shown in Figure 4-2

Figure 4-2

4.1.2 Class Axioms

4.1.2.1 owl:equivalentClass

OWL-G Definition 13

Notation

An owl:equivalentClass relationship is represented with a filled square connecting two classes. Since equivalent relationship is symmetric, the arrow can be omitted. If user wants to keep the original specification, the arrow head can be used.

4.1.2.2 owl:disjointWith

OWL-G Definition 14

Notation

The owl:disjointWith is shown as a broken line connecting the two classes. Again, the arrow head is optional since owl:disjointWith is a symmetric property as well.

4.2 Properties

4.2.1 Property Relations

4.2.1.1 owl:inverseOf

OWL-G Definition 15

Notation

The owl:inverseOf use the same symbol for owl:complementOf. Since one describes the relations between class and the other between properties, the same symbol won't cause any confusion.

4.2.1.2 owl:equivalentProperty

OWL-G Definition 16

Notation

The owl:equivalentProperty use the same sign as owl:equivalentClass.

4.2.2 Special Properties

OWL defines six special kinds of property. Regarding the datatype of the object, there are owl:ObjectProperty, owl:DatatypeProperty and owl:AnnotationProperty. Regarding the characteristics of global cardinality constraints, there are owl:FunctionalProperty and owl:InverseFunctionalProperty. In terms of the logical characteristics of the property, there are owl:TransitiveProperty and owl:SymmetricProperty.

OWL-G Definition 17

Rules OWL-G 17 specifies a shorthand notation for representing these special type of properties. For instance, in OWL-G rule 18, instead of entering "(owl:DatatypeProperty)", it can be shorthanded as (D) to indicate the property is an owl:DatatypeProperty. Although, the rule only saved a few characters, I believe it is useful for the design phase in particularly when a property belongs to several types of those properties.

OWL-G Definition 18

Rule 18 is mainly designed to shorthand the DatatypeProperty. So instead of drawing out another resource, the data type can be directly entered in the second compartment. Please note the different shape of DatatypeProperty and the regular two-compartment Property symbol.

4.3 Individuals

4.3.1 owl:sameAs

OWL-G Definition 19

Notation

The owl:sameAs is expressed as a filled circle.

Memory tip: Anything filled indicate some kind of equality. A squared shape is for "category" like of entities, such as class and property, both of which has sharp corner. A circle is for individual, which has round corner.

4.3.2 owl:differentFrom

OWL-G Definition 20

Notation

See the memory tips. The filled indicate something "=" while the divided indicate something which is "not". For class it is complementOf, for property it is inverseOf. But both of which use a square symbol. For individual we always use circle.

4.3.3 owl:AllDifferentFrom

OWL-G Definition 21

Notation

Because owl:AllDifferentFrom must applies to a list so a difference symbol is applied the list to indicate the relationship.

Presentation options

If the list is used only to shown the members are all different, the rightmost form of OWL-G Definition 21 can be used. If the order of element is not important, the numbered edge is not required either.

4.4 Ontology Header and OntologyProperty

4.4.1 Ontology symbol

OWL-G Definition 22

Notation

An ontology has the similar semantics as the namespace or package concepts. The UML notation of package is used to indicate an ontology.

Presentation Options

The name of the ontology can be entered either in the body or the tab of the package symbol.

A package symbol can be used in conjunction with a text pad to enter Ontology properties such as owl:versionInfo, owl:priorVersion etc.

OWL-G Definition 23

4.4.2 Compatibility symbol

OWL-G Definition 24

OWL-G Definition 25

Notation

The notation used to indicate the ontology relationship is overloaded with the individual. A solid circle indicates the backward compatibility where a half-filled circle indicates incompatibility. Note, because the discussion of an ontology always has a central topic, i.e., the newest ontology, so the arrow head shall not be omitted.

4.4.3 Deprecated entities

OWL-G Definition 26

OWL-G Definition 27

Notation

A deprecated entity, class or property, is shown as the regular notation with the top left corner marked by a filled triangle.

Examples

The example shown in OWL-R section 7.4.5 of the follow:

<owl:DeprecatedClass rdf:ID="Car">
  <rdfs:comment>Automobile is now preferred</rdfs:comment>
  <owl:equivalentClass rdf:resource="#Automobile"/>
</owl:DeprecatedClass>

can be depicted as Figure 4-3.

Figure 4-3

1. RDF Primer [http://www.w3.org/TR/rdf-primer/]

2. OWL Web Ontology Language Reference [http://www.w3.org/TR/owl-ref/]