Markup Languages: Comparison and Examples

Yolanda Gil and Varun Ratnakar
USC/Information Sciences Institute
TRELLIS project

Below is a comparison table that we created to understand the tradeoffs and differences among markup languages.  It compares XML (eXtensible Markup Language), RDF (Resource Description Framework), and DAML (DARPA Agent Markup Language) by showing a description and examples of how each language addresses common knowledge representation requirements.

We are preparing an article describing this comparison in detail.  If you have any comments or suggestions, please email them to us !

Our interest in markup languages stems from :
-  Research on TRELLIS, a framework to help users create semantically annotated traces and rationale for their decisions.
   A prototype of TRELLIS has just been released and you can try it here.
- Our research on PHOSPHORUS, an ontology-based agent matchmaker that the ISI Electric Elves framework uses to support human organizations.

Note:A paper has been published related to this work and can be found here. A few changes have been made to the table shown below (it will be updated soon)

Dimension XML (Schema) RDF (Schema) DAML Notes 
Contexts Default Namespace : xmlns
Declaring others : xmlns:<label>

XMLSchema Namespace (typically labelled xsd)
[Final W3C Recommendation]

targetNamespace refers to the namespace defined by the current file.

Example Namespace Declarations

Note: Namespaces need not point to anything in the XML Namespaces specification.
<xsi:schemaLocation..> provides the location of the schema.

RDF uses XML Namespaces.

RDF Syntax Namespace

RDF Schema Namespace
xmlns:rdfs = ""

Example Namespace Declarations in RDF

Note: In RDF, the namespace URI reference also identifies the location of the RDF schema


DAML also uses XML Namespaces.

It uses RDF & RDF Schema elements by referring to 
their respective Namespaces.

The latest DAML Namespace

Example Namespace Declarations in DAML

In DAML, we have to Import ontologies to be able to use the classes defined in the ontology.

Object Classes & Properties

No concept of classes and properties,
only Elements of certain Types.
The Type can be simpleType or a complexType.

(A class could be any element & its property could be its child element - NO DEFINED SEMANTICS)

Resource is the top level class.

Example of Classes, & Properties

Cycles in class hierarchy were not allowed till a little while ago. Latest revisions to the RDF spec allow this.

DAML also has Classes & Properties.
Classes can also be a subClassOf an anonymous class created due to a 'Restriction' on the set of all 'Things'.

Two kinds of Properties are defined:
ObjectProperties (Relate an object to another object - the value of the property is also an object)
DatatypeProperties (Relate an object to a primitive data type - the value of the property is a primitive data type)

Cycles in the class hierarchy are allowed.


Inheritance Since there aren't any Classes, there is no concept of inheritance.

However, Types can be extended or restricted , thus defining subTypes.

A class can be a subClassOf other classes (multiple inheritance is allowed)

Properties can also be subPropertyOf other properties.

Same as in RDF.  

Property / Element Range

Can be specified globally.
For a locally specificied (element specific) range, the element has to be declared locally.

Example of a global element.
The global element can be referred to like this.

Example of local element

Can only be specified globally

Multiple range statements imply conjunction (i.e. all of them should be satisfied)

Example of a range specification

Can be specified globally (<rdfs:range...>) 
as well as locally

Multiple range statements imply conjunction (i.e. all of them should be satisfied)

Range specifies the kinds of values (elements / classes / datatypes) the property can have.
Property / Element Domain No explicit declaration of the domain of the element. The domain is implicitly the element in which the definition appears. Can only be specified globally

Multiple domain statements imply conjunction (i.e. all of them should be satisfied)

Example of a domain in RDF here.

Can be specified globally (<rdfs:domain...>).

Multiple domain statements imply conjuction (i.e. all of them should be satisfied)

Example of a domain in DAML

Domain specifies which elements / classes can have the particular property
Property / Element Cardinality
Can be specified using
minOccurs, maxOccurs


Not defined in the core RDF Schema. By default there are no cardinality restrictions on properties.

However, new constraints like these can be specified by making them a subClassOf the 'ConstraintProperty' Class.
Look at how cardinality is defined in  OIL-Ontology

Can be specified locally
minCardinality, maxCardinality, cardinality

Can also be specified globally although only as a UniqueProperty (single valued i.e. having cardinality of 1).

The cardinality of a property specifies the number of occurences of the property/element for a certain class/element.
Basic Datatypes Datatypes supported by XMLSchema are mainly variations of numerical, temporal and string datatypes.

For a hierarchy of all built-in datatypes visit
this link.

The core RDF Schema only includes 'Literals' which is the set of all strings.

Example of the use of Literals. (The latest RDF spec is expected to include XMLSchema datatypes)

Allows the use of XMLSchema Datatypes by just referring to the XMLSchema URI.
More information can be found here.
Enumeration of Property Values Possible with the <enumeration> tag.

See an example here.

Not possible. Enumeration of property types is possible with the <oneOf rdf:ParseType="daml:collection"...> tag
See an example here.

It is also possible to simply point to an enumerated data type declared using XMLSchema.

An Enumeration restricts the value space of a property to a certain set of values.
Ordered Data Set Data Sets maintain order by default

Note: Type declarations having the <sequence> tag, just mean that data should appear in the order specified

Data Set ordered with the <rdf:Seq...> tag

Example can be found here.

Can use the <daml:list> tag  
Bounded Lists Not possible to specify. Not possible to specify. Possible with the <daml:collection> tag  
Transitive Properties Not possible to specify. Cannot be stated. Possible with the <daml:TransitiveProperty> tag

See an example.

Negation Not possible. Not  present. Possible with the <daml:complementOf..> tag


Negation implies the absence of some element (ex. no Car is a person)
Disjunctive / Disjoint Classes A union of possible types for an element is possible with the <union> tag


Can use a Bag to Indicate unordered collections (or unions of properties).

However, we cannot have a class as a union of 2 classes.

A Class can be a union of 2 other Classes. Possible with the <unionOf...> tag.
We can represent disjoint unions with the <disjointUnionOf...> tag.


Necessary & Sufficient conditions for Class Membership


(although <unique> could be interpreted as an UnambigousProperty)

No Yes

sameClassAs, equivalent, using boolean combinations of Class Expressions.

UnambigousProperty specifies a property which identifies the resource (like a primary key).


Necessary and Sufficient conditions for Class Membership specify a class definition that can be used:
1) to determine (or recognize) whether an instance belongs to that class
2) to determine (or classify) wheteher the class is a subclass of another class.

If there are any comments or suggestions, you can mail either Yolanda Gil, or Varun Ratnakar.