he semantic web, or what is often called Web 3.0, is a collection of technologies that associate meaning
with individual data elements that are usually embedded in XHTML files. Having precise semantics for each data element allows collections of highly specialized languages to evolve quickly, and developers can use sets of little languages designed to fit together precisely to create entire applications without having to use procedural languages. These systems are easier to maintain and empower business units to create and update their own applications and business rules. The growth of the semantic web and progression of little languages will have a dramatic impact on the skills needed by software engineers and IT strategists (see the sidebar, " The Darwinism of Software Languages
This discussion provides an overview of several specialized, semantically precise languages that are evolving to fill specific niches in developing web-based applications. Some languages may be familiar already to web developers, but some of the newer languages are being created to support semantic web technologies.
One of the first steps in any software project is to gather requirements. In the past, requirements were gathered by using a variety of techniques such as interviewing subject-matter experts (SMEs), writing lengthy requirements documents, or employing rapid prototyping. These processes suffered from the problem that either the SME isn't familiar with the software development process, or the software developer doesn't understand the subtleties of the business. As a result, the systems delivered sometimes don't match the needs of the users.
A more precise way to build applications requires SMEs and other nonprogrammers to draw pictures using a pallet of well-defined components. These pictures capture requirements by allowing the SME to determine constraints of the components and rearrange these components at any time. The components are precisely defined data elements taken from a central metadata registry where external parties define precisely the semantics of registered items, usually. These structured diagrams are saved or transformed into XML files while retaining the mappings of each data element to the metadata registry. Examples might be XML schema diagrams, workflow diagrams, or a listing of business rules with simple if, then, else sections. Users familiar with creating email rule files that automatically categorize incoming email may already be familiar with simple rule files.
This first stage of gathering requirements is often called the requirements elicitation phase. In this stage you ask the questions, what language should be used to capture these requirements? And, how do I specify what the SMEs want to build without specifying how these systems are built and deployed? The tools or languages to use will vary. If you create a simple web form, you may draw an XML schema that specifies the order of fields and their cardinality (which fields are required, and which fields repeat). As a family, these requirement-capture languages are called declarative languages.
The term declarative language is used to describe little languages for gathering precise requirements. Although there is still some confusion around the term "declarative" (it is both an attribute and a taxonomy of computer languages), most people agree that these languages focus on the whatnot the how or the requirements, and not the run-time implementation. They are by definition more abstract than a simple object class or a function. The process of transforming a requirement into a functioning application (the how) can be delayed. This process is also known as late binding and has an analogue in messaging and polymorphism.
The creation of small, specialized languages is not a new concept. The Unix operating system developed a way for small command-line tools such as sed, awk, sort, and uniq to be piped together to create a chain of operations on a data stream without using intermediate files. Some writers refer to these languages as domain-specific languages (DSLs). Regardless of their names, these languages share common properties:
- They have small vocabularies, usually fewer than 100 data elements.
- They favor pattern matching and transformation over explicit, complex if-then or looping logic.
- They avoid the process of creating new abstractions with private labels and unclear semantics. Using declarative languages usually is a matter of using elements that have publicly defined semantics.
- They avoid the creation of new functions, classes, or methods that have meaning only to the authors and their peers.
- They focus on the placement and ordering of their elements in files.
- International standards bodies can take a very long time to agree on their structure.
Vital to these languages is a community process that is used to define the meaning of each of the data elements in the language. The larger the community that participates in defining a data element, the more widely it will be adopted by tools vendors. The better the tools, the lower will be the support and maintenance costs. The more software developers who become familiar with these standards, the higher there is a probability that future developers will be found that are familiar already with the semantics of the languages and the requirement-gathering systems.