Recommended Article: Why is Business Semantics the New Hot Topic?
Labels:
semantics technologies
Why is Business Semantics the New Hot Topic?
Quote:
Q: Can we talk more about ontologies? What is an ontology and why is it useful?
McComb: The most commonly quoted definition (from Tom Gruber of Stanford) of an ontology is "a specification of a conceptualization." Or, to put that slightly differently, an ontology is a formal way to organize knowledge and terms. Typically ontologies are represented as graphical relationships or networks, as opposed to taxonomies which are usually represented hierarchically.
As to why they are useful? Well, in any system (be it computer-based or in the world at large), we need to have agreement on the meaning or terms and their interrelationships in order to share understanding. In the IT world, software and software agents act upon these meanings, so there need to be specific "commitments" to the meanings in the system. Paraphrasing Gruber again, we build software and agents that commit to ontologies, and we design ontologies so we can share knowledge among the agents. The value (to answer the original question) then comes from the ability to share and re-use knowledge between agents in the system.
Ontologies are like UML class diagrams, only much more general. An ontology is used to define concepts, not to define data structures or encapuslations of state and behavior. There is a difference of purpose. Is there an analogy to classes? Certainly--but there are also important differences.
In an ontology, one not only formally defines concepts, one also formally defines the properties of each concept. Properties are first-class values--both at the base level (instances) and at the metalevel.
One can define both "monthOrdinal" and "monthCardinal" as properties, binding "monthOrdinal" to the "ordinal number" metaproperty, and binding "monthCardinal" to the "cardinal number" metaproperty.
One may also define declarative logic translation rules that apply globally within the knowledge base. For example, one such rule might say that "monthCardinal" should always be translated to "monthOrdinal," and another rule might say that when translating a cardinal number to an ordinal number, the value of the destination property should be 1 greater than the value of the source property.
No comments:
Post a Comment