In the years since the SHOE project was started, several other languages have come along for describing ontologies on the web. The most recent, and currently most used, is a language called DAML+OIL which was developed under joint sponsorship of US and European government agencies. DAML+OIL is based on the Resource Description Framework (RDF) which is in turn based on the eXtensible Markup Langauge (XML). To really explain DAML+OIL in detail would involve a signficant amount of explanation of these languages. Instead, we will concentrate only on the markup and ontology issues without dwelling on the details of the syntax.
One key difference between DAML+OIL and SHOE is that DAML+OIL does not assume that the markup lives on the same page as the object being described. In fact, the practice has become to have a separate page, using a ".daml" extension, which describes information in a manner intended for computers, not for humans. To see the gory details, you can go to http://www.cs.umd.edu/users/hendler/jhendler.daml , below we only show a part of this page.
<rdf:RDF
[several lines deleted]
xmlns:StanfordKSL="http://www.ksl.stanford.edu/projects/DAML/ksl-daml-desc.daml#"
[several lines deleted]
xmlns ="http://www.cs.umd.edu/users/hendler/jhendler.daml#"
>
The file starts by declaring it is written in the RDF syntax and then defines a number of XML namespaces it uses. For the purpose of this discussion, you can think of these namespaces like the prefixes used in the SHOE example in Step 2. Thus, we say that the prefix "StanfordKSL:" will be used to refer to the DAML ontology described in the URI that follows. Multiple namespaces can be referred to (this file uses ten of them). The final line says that if no other namespace is used, the default should be this file itself.
In DAML+OIL we typically define instances by stating what class they are in, and then what their properties are. (Combining a number of things that were separate statements in SHOE). Information about one entity can be provided by referring to a number of different ontologies. We can separate these into parts (which could even be defined on different web pages) - here's an example of the information for Professor Hendler relating him to several different terms defined in different ontology pages.
First, let's look at the whole thing, and then we'll look at some of the pieces.
<StanfordKSL:Person rdf:ID="JimHendler">
<StanfordKSL:has-Full-Name>Professor James A. Hendler, PhD</StanfordKSL:has-Full-Name>
</StanfordKSL:Person>
<ShoeGen:Person rdf:about="#JimHendler">
<ShoePers:emailAddress>jhendler@darpa.mil</ShoePers:emailAddress>
<ShoePers:child> http://www.cs.umd.edu/users/hendler/sharon.html</ShoePers:child>
<ShoePers:age>about 44 </ShoePers:age>
<ShoeGen:head rdf:resource="#PlusLab" />
<dex:hasHeight rdf:resource="http://www.daml.org/2001/03/daml+oil-ex#short" />
<CmuAtlas:sex rdf:resource="http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0.daml#Male"/>
</ShoeGen:Person>
Pretty complicated, but much of that is syntax that is needed to allow modern web tools to properly handle the XML and RDF. Let's go through it in a little more detail:
<StanfordKSL:Person rdf:ID="JimHendler"> <StanfordKSL:has-Full-Name>Professor James A. Hendler, PhD</StanfordKSL:has-Full-Name> </StanfordKSL:Person>This first one is relatively straightforward, and could have been done in SHOE. It says that there is a Person (as defined by the ontology which we named StanfordKSL:). The ID of this person is "JimHendler" - but actually it's a but more complex than that. Since we didn't state a namespace, this used the default namespace which is this file. Thus, this really is shorthand for "http://www.cs.umd.edu/users/hendler/jhendler.daml#JimHendler" which is a unique URI - this is important, it means this identifier can be used by that (whole) name anywhere on the world wide web, and we can come back to this particular place on this particular web page. This is a good example of the use of URIs as discussed in the article.
We also go on to say that this instance has a Full-name (which is a string) of "James A. Hendler" and that's it. The property doesn't need all those argument things we had in SHOE because DAML+OIL's use of RDF and XML syntax precludes some of the problems SHOE had with argument order.
Now let's look at a more complicated example:
<ShoeGen:Person rdf:about="#JimHendler"> <ShoePers:emailAddress>jhendler@darpa.mil</ShoePers:emailAddress> <ShoePers:child> http://www.cs.umd.edu/users/hendler/sharon.html</ShoePers:child> <ShoePers:age>about 44 </ShoePers:age> <ShoeGen:head rdf:resource="#PlusLab" /> <dex:hasHeight rdf:resource="http://www.daml.org/2001/03/daml+oil-ex#short" /> <CmuAtlas:sex rdf:resource="http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0.daml#Male"/> </ShoeGen:Person>Here we are identifying more information about the same person. We know it is the same person because we use the same URI (the rdf:about is the way we say this). But now we're saying that not only is JimHendler a person as defined by StanfordKSL, but he's also a person as defined in the ontology ShoeGen (somewhere else on the web). We go on to say what his email address is, that he has a child (and names her web page), what his age is, that he's the head of something called the PlusLab, that his height is short and that he's a male. All of this information is related to specific terms. Note also that we can mix different ontologies by use of the many prefixes we defined above. This lets us provide information in one place that might not have been defined in another. So, for example, the ShoeGen ontology doesn't happen to have a property for sex, but we wanted to state that Dr. Hendler is a male. We used a different ontology (called CmuAtlas) which did have this property, and related it in.
Let's look at one other example from this file
<rdf:Description rdf:about="http://www.cs.cmu.edu/~softagents/atlas/ontologies/atlas-cmu.daml#Project"> <daml:equivalentTo rdf:resource="http://www.cs.umd.edu/projects/plus/DAML/onts/general1.0.daml#Organization" /> </rdf:Description> </rdf:RDF>Here we use an important feature of DAML+OIL. We happen to have discovered that the CmuAtlas and ShoeGen ontologies had different names for the same concept. We state, in a formal machine-readable way, that these two terms are equivalent to each other. This is useful because it can let an agent (or tool) that knows about one of these terms communicate with an agent (or tool) that knows the other. Note, however, that we don't use the prefixes here. This is a byproduct of the way XML is designed and thus DAML+OIL uses this syntax. (Note that we close the RDF definition we made at the beginning of the page.)
The DAML+OIL ontology language is much richer in many ways than the SHOE language was. It also is defined in such a way that it conveys a more rigorous semantics and, of course, uses the RDF and XML syntaxes. In the following, we will only describe those things in this language that were similar to those in SHOE (and used above). For a more complex annotated example, which shows much more of the richness of the language, see http://www.daml.org/2001/03/daml+oil-walkthru.html.
< <rdfs:Class rdf:ID="Person">
<rdfs:subClassOf rdf:resource="#Organism"/>
</rdfs:Class>
As discussed above, DAML+OIL uses classes for what SHOE called categories. In this case we say that there is a class named "Person" and that it is a subclass of "Organism." The class/subclass relation in DAML+OIL is defined more formally than the "ISA" was in SHOE, but it's basically the same idea.
< <rdf:Property rdf:ID="has-Full-Name">
<rdfs:domain rdf:resource="#Person"/>
<rdfs:range rdf:resource="#String"/>
</rdf:Property>
As in SHOE we can define properties that relate one class to another. Thus "has-Full-Name" is simply stated to relate a Person to a String. The use of rdfs:domain and rdfs:range replaces the argument structure that was shown for SHOE in Step 2, Part 2.
However, DAML+OIL can do a lot more than SHOE could. For example, consider
<<daml:Class rdf:ID="Person">
<rdfs:subClassOf rdf:resource="#Animal"/>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="#hasParent"/>
<daml:toClass rdf:resource="#Person"/>
</daml:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<daml:Restriction daml:cardinality="1">
<daml:onProperty rdf:resource="#hasFather"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
This is the definition of a person from the example ontology mentioned above. It says not only what class and subclass we're talking about, but it also defines some properties of the class and puts some restrictions on them. In this case it says that a person is a kind of animal, that a person has a property called "HasParent" which relates this person to another one, that the person has something called a "hasFather" which is a kind of "hasParent" - but that the person is restricted to have one (and only one) father. (Note: there was some discussion about whether this rule was true. It was noted that we were referring to biological fathers and, at least within current technological bounds, this was a valid restriction.)
DAML+OIL shows how modern ontology languages are becoming more powerful and also more embedded on the web -- that is, they are more tied into advanced web languages (as discussed in the article). However, as the languages get more complicated, it gets harder for users to harness the full expressivity of the language, and harder for users to check to see whether the ontology someone else designed has the meaning they expect. There are a number of research areas that are opened up by these languages, and their complexity, including issues of tool design, language display, and the use of the ontologies by more complex web agents. Discussion of these issues and examples of the way DAML+OIL is addressing them can be found on the DAML Home Page .
However, lest we leave the user thinking these languages are so complex that no one could use them, we offer one more example -- a notation that was derived to make it easier for humans to interact with these more complicated web syntaxes.
Return to example description.
Go on to Step 4