DLG²- A Graphical Presentation Language for RDF and OWL (v 2.0)

Latest version: http://www.charlestoncore.org/dlg2/. Release date: July 27, 2005

Previous version: http://www.charlestoncore.org/docs/dlg2.html

Major changes since 1.0

Previous version of DLG² is an ad hoc collections of notation symbols that I found useful for helping ontology design. At that time, most design efforts are directed toward making meaningful but concise graphs and the formal semantics of the language has not been put in agenda. In this version, the lagnauge was given formal rigor in the semantics of the language. Here are some major adjustment in response to the change.

• The original DLG² document is broken into three parts. RDF-G and OWL-G are now considered default extension - but not core - packages. Each of the package has their own document URI. The URI for RDF-G is "http://www.charlestoncore.org/dlg2/rdf/", and "http://www.charlestoncore.org/dlg2/owl/" respectively.
• A package notation is added to the DLG package. The notation is used causually previousely with ambiguous semantics. In the current version of DLG², package notation is formally defined.
• Each graph pad is mandated to be associated with a URI so the enclosed substitution sentence can be consistently accessed.
• A dependency compartment is added to graph pad. The semantics of URI of the substitution sentence is formally defined in this document.
• All text in DLG² shall follow the syntax of Notation-3^[1]. Using RDF/XML in a graph appears to be very awkward and it is no longer recommended.

Rationale

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 Resource Description Framework (RDF) models. It is worth to note the presented language is designed mainly to aid human communication but not for machine interoperation. 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 actually mean is a human interoperability but mediated by the 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 is achieved through shared ontologies, where the design, promotion, adoption and implementation are mostly human activities. If we take the view point that the features of a communication system results from the interaction between system constraints and job demands^[2], 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 (machine only take message in serial fashions) in languages like RDF/XML, Notation 3 etc. To make human understand better, the model needs to be graphicalized 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.

Theoretical foundations

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 substitution definitions, we can use a more concise but comprehensive graph to represent the verbose graph. But to use the C-formalism shown in Figure 1-1 doesn't suit the nature of a 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.

Basic Principles

Principles of equivalence

Any language needs to address both its syntax and semantics. For a visual language, the syntax concerns the physical layout of the diagram and its semantics concerns the meanings ascribed to the symbols. DLG² only specify the meaning of a few symbols and use two principles of equivalence to extend the semantics of a diagram.

Two principles of equivalences are

1. A simple DLG² graph is semantically equivalent to a corresponding RDF graph.
2. Two DLG² graphs are semantically equivalent if they are substitable with each other.

The first principle grounds the semantics of a DLG² graph to that of an RDF graph; The second principle extends the RDF semantics to practially any notations. The two principle gives DLG² a precise semantic while keeping it flexible.

Textual Message

Despite the fact that DLG² is designed to be a graphic language, its design does not exclude the use of textual message. Text is not only a necessary component in terms of labelling the graph but also more convinient than graph to express certain abstract concepts. The ultimate purpose of developing DLG² is to facilitate human communication. In situiations where text message is more suitable as a communication tool, we encourage users to use text based message.

Syntax

The syntax of text message uses the same convention as that of N3. Such a choice is made to avoid reinventing the wheel. N3 is choosen over RDF/XML for its more human friendly syntax and concise form.

Character Encoding

As a graphical notation language, text in DLG² is encourage to be encoded in its visual representation rather than the Nomalized forms of UNICODE string.

Semantics

The semantics of text in DLG² shall be converted to simple DLG² graph, which in turn will be mapped to an RDF graph before the sematnics is offered.

Infrastructure

DLG² is built on two core packages: (1) The DLG package contains the primitive notations for constructing an RDF graph in the most elementary form of a directed labeled graph and (2) The Transformation package contains auxilary notations that can be used to extend language vocabulary. (Figure 1-2)

Figure 1-2 Core packages of DLG².

In addition to these two core package, DLG² has also defined two extension packages. The first one is called RDF-G, which is designed to express concepts introduced in basic RDF and RDF schema language. The second one is called OWL-G, which 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

DLG Package

Because the syntax of RDF is officially described in graphical terms, each RDF model therefore corresponds a diagram in line with a DLG. We took the view point that the vice versa of the above statement shall also be true as well. That is: any DLG graph can be expressed in RDF as well. The DLG package of the DLG² formally specifies the correspondence between the RDF model and a DLG graph.

DLG² adopted the conventions used in many existing RDF literatures and defines three primitive notations for resource, property and literal values. Resource is represented as an ellipse; A property is represented as a line with an arrow head; a literal is represented as a plain rectangle.

Resource

Notation

A resource is anything with an URI. The graphic representation of a resource is an ellipse with its URI placed inside the ellipse.

To follow the most conventions of RDF literature, the resource URI can also be expressed in the form of a Qualified Name (QName) defined in XML namespace document. The prefix of the QName shall be defined by a package notation (see later section).

An ellipse without a URI indicates an anonymous resource or a blank node. Occasionally, if a user intends to label a blank node with a temporary node ID, the node ID shall be labeled according to the syntax of notation-3 by prefixing the node ID with "_:" (see Figure 2-1).

Figure 2-1: Notation for a resource

Property

Notation

A property is shown as an line with a solid triangle arrowhead connecting from the subject to the object of a RDF statement. The line without the arrowhead shall be connected to the subject of an RDF statement whereas the arrowhead must be connected with the object. The URI (or in the form of a QName) of the property shall be placed near the property line (see Figure 2-2).

Figure 2-2: Notation of a property line

Literal

Notation

A literal is shown as a solid outlined rectangle. The value of the literal is placed inside of the rectangle. The literal value follows the syntax of notation 3 (see Figure 2-3). According to notation-3, if langage is not specified, it is default to English. A string of quoted characters without any datatype URI is default to "http://www.w3.org/2001/XMLSchema#string"; An unquoted string without datatype URI is default to "http://www.w3.org/2001/XMLSchema#integer".

Figure 2-3: Notation for literal

Package

Notation

A package notation is shown as a three compartmented package sign shown in Figure 2-4

Figure 2-4 DLG² Package Notation

A package notation is used for the following three purposes.

1. It is used to indicate the namespace URI for the ontology in question. The namespace URI is placed at the tab of the package notation.
2. It is used to define prefix for use in QName to shorten the text label. The syntax of prefix definition, once again, follows the syntax of Notation-3. Prefixes "rdf:", "rdfs:", "owl:" and "xsd" are predefined. They do not need to be explicitly specified.
3. It is used to indicate the graphic notation package used. The document URI of the DLG² package shall be placed at the bottom compartment of package sign. The RDF-G and OWL-G are considered default package and do not need to be explicity specified.

Namespace URI vs. Document URI

It is worth to mention that top compartment of the package notation is used for namespace URI but not document URI. We emphasize it here because there exist two different styles in terms of the using URIs in RDF. (see Hash vs. Slash). Our purpose here is not to favor either side, but to clarify the intended use of namespace URI in package sign.

The full URI of a default element name in an RDF/XML document is constructed as following:

[Document URI] + # + [local name]

where the namespace URI is defined by the xml:base attribute of RDF element. For this reason, RDF document using the hashless URI will be unable to use default namespace because all hashless-URI documents use HTTP redirect to serve the definition document. Because the redirected document will have a different document URI, therefore a different xml:base, from what it is intended. Using default namespace or element will make the identify of element ambiguous.

The above rule, however, only make sense in RDF/XML. In Notation-3, for example, the "QName" is arbitrarily created (in the sense not syntactically licensed as it is in XML.) by prefix substitution. And there is no way to substitute an empty space in notation-3. Therefore, the default "QName" in Notation-3 is in the form of ":abcd".

Using document URI doesn't make much sense because a DLG² diagram will be often used to facilitate the presentation rather than the definition of an RDF model. Therefore, the actual document URI of a DLG² graph will likely be different from the document URI the DLG² is intended to represent. To allow the use of simple name to represent the concepts of interest, it is therefore defined in the following rules

the full URI of an unqalified name in DLG² is constructed by direct concatenation of the namespace URI specified at the top compartment of the package sign and the simple name itself.

Such a rule however may create confusion if the fragment identifier contains ":", which is allowed according to URI specification. For instance, how do we express http://www.example.org/foo/#urn:LSID:www.charlestoncore.org:strange:fragment in its simple form?

Assuming no prefix "urn" is definied, how can we tell if urn:LSID:www.charlestoncore.org:strange:fragment is a local name with namespace URI or acutally a LSID? The answer is no if no URI resolving algorithm is specified. The following algorithm nevertheless will disambiguate the difference and resolved it to an LSID. If a user intends to use a simple name containing ":", he or she must define the default prefix ":" and prefix its fragment identifier with ":".

Algorithm in resolving URI reference

Given a string uriName and the full URI for the uriName is created according to the following algorithm

Step 1. Find the first ":" of string uriName

If ":" is not found, go to step 2

Else go to Step 3

Step 2. Full URI = <Namespace URI> + <uriName>

Step 3. Take substring of uriName till the first ":" and check if the substring is defined as prefix

If so, Full URI = <prefix URI> + <text afer ":'>

Else, Full URI = <uriName>

Text in DLG Package

Text in DLG must be in either (a) extended URI (b) literal strings

Transformation Package

The transformation package contains three notations

• The identical sign "≡" is used to introduce substitute rule.
• A graph pad is the place holder for substitution definitions
• A text pad is used to extend the language with text based language

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

Substitution sign

Notation

The substitution sign is denoted as an identical sign "≡".

Semantics

A substitution sign is used in a substitution sentence as follows

LHG  ≡  RHG

where LHG denotes Left Hand Graph and RHG for right hand graph. The semantics of a substitution sign is to indicate that LHG and RHG are semantically equivalent and they are interchangable. 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

In order to write comprehensive substitution sentence, the following conventions are recommended

• Underlined text are treated as text variables
• All other text is explained as is

Graphic pad

The graphic pad is used to formally record substitution sentence.

Notation

Graphic pad is shown as a file folder symbol with the top compartment of the graph pad in a trapezia shape. (see Figure 2-5 ). Their intended meanings are as follows.

• The top compartment is used to enter the URI Reference of the substitution sentence being defined.
• The middle compartment record the substitution sentence.
• The bottom compartment is a list of substitution sentences. If more than one dependent URI reference are used, they shall be separated by semicolon. If none of the dependent URI is listed, the bottom compartment can be omitted.

Figure 2-5: Notation for graph pad.

Rule for assigning URI for substitution sentence

If the top compartment of URI reference must be an absolute URI. Such a restriction is based on the thinking of if a graph pad is accessed remotely, the base URI (document URI) would be easily merged into the graph.

The default base URI for the dependent URIs is the same as the top compartment URI. (i.e., the URI prior to the fragment identifier. If more than one URIs of the same base URI are used, they shall be separated by a comma. If more than one base URI are used, the list can be separated by "semicolon", only the first URI of each list shall be a full URI except for the default.

For instance, if a substitution sentence "http://first.example.com/#3" depends on four other sentences of the following:

• http://first.example.com/#1
• http://first.example.com/#2
• http://second.example.com/#a
• http://second.example.com/#b

The dependent list can be written as:

#1, #2;

http://second.example.com/#a, #b;

Example

To formally record the substitutions shown in Figure 1-1, for instance, they can be formally recorded as shown in Figure 2-6

Figure 2-6 An example of substitution definitions.

Text pad

There are many circumstances where lingistic expression outshines imagistic ones. For instance, writing a list in RDF is extremenly verbose due to the constraints of RDF that is only allowed to express binary relationships. To describe a list in RDF/XML needs the help of a linked-list type structure as a hook to construct the list. However, the design of RDF/XML is intended for the clarity of machine processing but not human comprehension. Human has a much higher cogintive capacity to comprehend abstract concepts. It is therefore much easier to use a text based representation in this case than drawing graphs.

Where to place the TextPad, i.e., under DLG package or Transformation package is a bit dilema to me. In principle, the Text Pad does not play an essential role to graph transformation. However, putting the text pad in the DLG package makes the semantics of the DLG package murky because a Simple DLG² Graph will no longer be simple.

Notation

A text pad is shown as a rectangle shape with a triangle embedded at the bottom right corner ( Figure 2-5 ). The text string within the text pad shall follow the syntax of notation-3. If a resource overlaps with a text pad, the resource shall be considered as the subject of all RDF statments in the text pad.

Figure 2-7: Text Pad

The text in a Text Pad shall follow the syntax of Notation-3. To the most extream, an entire notation-3 document can be placed within a text pad and still considered as a valid DLG² diagram.

To extend DLG² with a text pad, a graph symbol shall either overlap or connected with a text pad with a solid line. For instance, the example used in Notation-3 Primer that expresses "The 24 years old Pat has child 'al', 'chaz' and 'mo'" can be shown as in Figure 2-8

Figure 2-8 Two ways to extend with a text pad.

DLG² also defined two default extension packages of the graphical notations. The first extension is called as RDF-G. RDF-G defined graphical notations that is used to express concepts defined in RDF and RDFS. The definition of graphical notation is provided at "http://www.charlestoncore.org/dlg2/rdf/" The other extension package is called OWL-G. OWL-G, build on top of RDF-G, defines graphic notation for vocabularies specified in OWL. For details of OWL-G definition, please see "http://www.charlestoncore.org/dlg2/owl/"

Here are two examples where the entire RDF/RDFS and OWL specification can be denoted in DLG²

Figure 2-10 Definitions of RDF/RDFS vocabularies.

Figure 2-10 Definitions of OWL vocabularies.

The DLG² stencil for Microsoft Visio supports symbols defined in both core packages and default extension package of "http://www.charlestoncore.org/dlg2/rdf/" and "http://www.charlestoncore.org/dlg2/owl/".

The stencils for DLG² are beta versions and might be updated frequently. If you discover omissions or have suggestions for improvements please contact Xiaoshu Wang(wangxiao @ musc.edu).

Term of use

You can use, copy and modify the stencils as you like. If you use the stencil to create a publicly available document, such as book, paper or presentation, use some appropriate form of acknowledgement or make a reference to this web site.

Download

Don’t left-click the link, if you use Microsoft Internet Explorer! It will start Visio on your computer. Instead, right-click the link and select "Save Target As..." If you have difficulties downloading the files, please contact me.

Here is the link for the stencil. http://www.charlestoncore.org/downloads/dlg2.vss.

Extended URI: Absolute URI or QName

Literal String

Simple DLG² graph - A simple DLG² graph is a graph that is only composed with notations defined in DLG package.

Substituable graphs: If one diagram can be transformed to another by applying the substition sentences defined according to the Transformation package.

1. Berners Lee, T. (1998-) Notation 3: An RDF Language for the Semantic Web. (http://www.w3.org/DesignIssues/Notation3.html)

2. Hauser, M. D. (1996) The Evolution of Communication (MIT Press, Cambridge,MA).