Method and computer program product for converting ontologies into concept semantic networks

Abstract

A method and computer program product for producing a concept semantic network (CSN) from an ontology. Each class, subclass, object, restriction, and property of the ontology is converted into a concept of the CSN. Each hierarchy in the ontology is converted to a concept hierarchy of the CSN.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention described herein relates to analysis of unstructured information and, in particular, relates to text analytics.

2. Related Art

More than 80% of data being gathered by users of information systems is unstructured. This data may be in the form of emails, blogs, websites, documents, spreadsheets etc. As the number of computer and Internet users continues to grow, more and more unstructured data content is created. This is evident when observing the growth of the Internet and websites (about 10 million) and documents and emails residing on an individual's desktop. This growth of data has created a need for understanding and leveraging the data's content.

This has given rise to the emerging text analytics area. This area focuses on understanding, harnessing and linking contents of emails, websites, and text data, for example, in database records and documents (henceforth collectively called “documents”). The primary domain of expertise and knowledge comes from natural language processing (NLP), a sub-division of artificial intelligence (AI).

The advantages of text analytics are well-known and several text analysis techniques are increasingly adopted in all walks of life. Today, customer feedback through a company's website is analyzed immediately and accurately for negative tones. Once such tones are identified, they are immediately used with the rest of the customer data for personalized action. Law enforcement agencies use the text analysis techniques on incident reports to look for the modus operandi of suspected criminals. Such broad examples are plentiful. In spite of such compelling benefits and advantages, however, text analysis adoption has been limited due to several limitations in current processing techniques.

There are several methods/algorithms available in NLP that can be used in attempting to understand the language of a document and summarize what the document is about. The challenge has been to match the expectations of the reviewer with the output of the NLP algorithm(s).

Overcoming this challenge has been difficult and several approaches have been proposed with varied degrees of success. Key approaches in this area include:

• • Use of clustering techniques to identify key themes and patterns: These techniques are very useful in identifying themes of interest and then identifying nuggets of information around these themes. Usually, these techniques make assumptions about themes of interest and build clustered word patterns around those assumptions. As the entire process is automated, many times these techniques produce output that might not fit the user's interest. As a result, clustering is of limited value to situations where the user's interest is not centered on themes of interest.
  • Idea extraction techniques to summarize contents based on ideas: These techniques are based on the notion that the purpose of natural language is to communicate ideas and therefore, capturing ideas (for example, from a document) is tantamount to capturing the essence of communication. While these techniques have applications in several business and consumer areas, they cannot be easily adapted to identify conditions that do not form the main idea or theme but yet might be of interest to the user.
  • Semantic networks based on semantic indexing: Semantic networks are based on the notion of extracting semantic content from a document by combining like terms with the help of thesaurus, dictionary or other similar look-up tools. While these networks can accurately reflect contents, they tend to produce high volume of results for even small document sets and thus are not scalable.
  • Semantic and syntax analysis: These techniques take into account grammatical constructs within the natural language to pick up themes and patterns, to build a summarization. However, these techniques are computationally intensive and are not scalable.

What is needed, therefore, is a method and system for performing text analytics in a manner that avoids these shortcomings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a data flow diagram that illustrates the use of ontologies to help users analyze text.

FIG. 2 illustrates an example of a concept semantic network (CSN).

FIG. 3 illustrates another example of a CSN.

FIG. 4 illustrates an example of an ontology.

FIG. 5 illustrates the ontology of FIG. 4, with an expanded list of subclasses.

FIG. 6 illustrates a CSN resulting from the ontology of FIG. 5.

FIG. 7 illustrates an example of a graphical user interface (GUI) used to capture a user's preferences in assigning concept types.

FIG. 8 illustrates a CSN that reflects the inheritance of properties that occur in a related ontology.

FIG. 9 illustrates an example of a graphical user interface that allows a user to customize concept definitions and relationships in a CSN.

FIG. 10 illustrates a computing platform on which the invention can be implemented.

Further embodiments, features, and advantages of the present invention, as well as the operation of the various embodiments of the present invention, are described below with reference to the accompanying drawings.

DETAILED DESCRIPTION OF THE INVENTION

A preferred embodiment of the present invention is now described with reference to the figures, where like reference numbers indicate identical or functionally similar elements. While specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the relevant art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the invention. It will be apparent to a person skilled in the relevant art that this invention can also be employed in a variety of other systems and applications.

In order to overcome automated methodology limitations, several techniques have been proposed over the years:

• • Manual intervention is used in several algorithms to refine matching user expectations with that of the algorithm: This approach allows the user to direct the algorithm to identify themes, patterns and trends around their areas of interest. Several products offer such capability for the user to specify their interest and use that to analyze text data on a broader scale. The challenge here is to capture the user's interest in a formal and systematic way.
  • Ontologies are the product of attempts to formulate exhaustive and rigorous conceptual schemas about different domains. A domain does not have to include the complete knowledge of that topic, but is a domain of interest decided upon by the creator of the ontology. Ontologies are said to have strength or weakness based on the ability of a computer to comprehend them. A paragraph of written text can still technically be defined as an ontology, but is a weak ontology. An ontology defined in an ontology language such as OWL (web ontology language), for example, or in another suitable language, is a strong ontology, as a computer can understand the complete meaning (or semantics) of the contents (http://www.w3.org/TR/owl-guide). A strong ontology can be said to be machine-readable. In this description the focus will be on strong ontologies (henceforth referred merely as ontology or ontologies). Since the strong ontology can be part of a formal process with well-defined grammatical constructs, it can accurately capture and store a user's interest.

The popularity of ontologies appears to be growing. The ability to rigorously capture, store and reuse the conceptual schema about a domain makes ontologies attractive for diverse user communities. For example, the Semantic Web initiative is a project that intends to create a universal medium for information exchange by giving meanings (semantics), in a manner understandable by machines, to the content of documents on the Web. The Semantic Web extends the World Wide Web through the use of standards, markup languages and related processing tools. One of the main components of this initiative is capturing the representation of knowledge (which reflects a user's interest) in a formal way (http://www.w3.org/2001/sw).

Because of this initiative, several public sector organizations and private sector companies have been working on building ontologies that formally capture rich meta-data. If used appropriately, these meta-data structures can help users analyze text content. This can be done formally in the areas of user interest. A high level system flow diagram is shown in FIG. 1, which illustrates the use of ontologies for analysis of textual information. Here, a user creates one or more ontologies, which are used in an analytical engine, along with text or database input. The results can be generated in a graphical form, e.g., graphs and charts, which can then be analyzed by the same or different user.

Thesauri are widely thought of as special purpose ontologies where classes/objects are called “terms” with a limited set of relationships between these terms, as defined in the ANSI/NISO Z39.19-2003 US standard entitled “Guidelines for the Construction, Format, and Management of Monolingual Thesauri” and its equivalent international standard ISO 2788. Unlike ontologies, which allow any user-defined relationship between classes, thesauri allow only the following relationships between terms:

• • BT=broader term
  • BTG=broader term (generic)
  • BTI=broader term (instance)
  • BTP=broader term (partitive)
  • GS=generic structure
  • HN=history note
  • NT=narrower term
  • NTG=narrower term (generic)
  • NTI=narrower term (instance)
  • NTP=narrower term (partitive)
  • RT=related term
  • SEE=equivalent to U (USE)
  • SN=scope note
  • TT=top term
  • U=use
  • UF=used for
  • UF+=used for . . . and . . .
  • USE+=use . . . and . . .
  • X=see from (equivalent to UF); reciprocal of see

Based on the fact that thesauri are specific instances of ontologies, the method described herein for mapping ontologies to concept semantic networks (CSNs) can be used to map thesauri to CSNs as well.

A concept semantic network can be viewed as a set of ideas or concepts that are interrelated and represent one's beliefs about a certain topic. Humans develop ideas or concepts about almost every topic and these concepts can change as people learn more about these topics. A CSN becomes very useful in text analytics where users need not think about “keywords” like search engines do but rather about concepts. Once a concept is defined, the definition can be reused multiple times. FIG. 2 shows an example CSN that has definitions for “Automobile,” “US Automobile,” and “Imported Automobile” concepts. Notice that “Automobile” is defined in terms of the latter two concepts. Also “US Automobile” and “Imported Automobile” are in turn defined in terms of other concepts. According to the definition given in FIG. 2, when user uses “Automobile” he or she in fact means “US Automobiles” and “Imported Automobiles” which, in turn, get resolved to “Ford” and “Toyota” respectively. Of course a more complete definition might have included all US automobiles and all imported automobiles.

In other words, a concept can be defined in terms of other concepts. Another example is the concept “North America” which can be defined in terms of concepts “USA,” “Canada,” and “Mexico.” Recursively, any of these three concepts can be defined in terms of other concepts. These multi-level definitions build what is called a concept-hierarchy.

A concept can be part of multiple concept hierarchies. For example the concept “North Atlantic Treaty Organization” can be defined in terms of concepts representing member countries which include “USA” and “Canada.” Now we have “USA” and “Canada” as members of two concept hierarchies. A concept semantic network may contain one or more concept hierarchies. A valid concepts grammar is described in Appendix II.

Concepts can be as simple as a single word or a phrase, or can be a complete hierarchy, as shown in the above examples. A concept may also be a complex construct of other concepts linked using logical operators such as “AND,” “OR,” and “NOT.” Using the above example one could define a new concept of “Toyota AND Ford NOT Honda.” A complex concept can be resolved by substituting the definitions of its sub-concepts. Appendix II provides an example of a formal grammar for complex concepts. Once simple concepts are extracted from ontologies, they can be used to construct complex concepts within a CSN to provide a new level of comprehensiveness that is not possible in ontologies.

As indicated above, ontologies are developed mainly for machine consumption, which makes them less useful for human users despite their rich content. On the other hand, concept semantic networks are more user-oriented. Users are accustomed to view things as related “concepts” or “ideas.” One of the challenges that face CSN users is how to create CSNs and maintain them effectively. This challenge can be overcome with variable degrees of success using one or more of the following approaches:

• 1. Manually define concepts.
  • This is a very time-consuming process and does not scale well, just like any manual process. It also requires solid understanding of the topic for which the CSN is constructed, which may not always be possible. These two factors make manual concept definitions a less favorable option among end users.
• 2. Automatically extract concepts from text corpora.
  • This is a more scalable method that is based on analyzing textual contents of text corpora, identifying important topics (thematic, exceptional, or both), and extracting those concepts. This approach is very helpful particularly in situations where user lacks deep understanding of the document contents/topics. The automated extraction can be done in two different ways:
  • a. Supervised: The user seeds the process with a few concepts that he/she is particularly interested in, and the process identifies and extracts only concepts related (relevant) to the seed concepts.
  • b. Unsupervised: The user does not provide any input to the concept extraction process. The extraction process analyzes the contents using a combination of natural language processing and statistical algorithms to identify the most prominent concepts in the corpora and also discovers the relationships that may exist among them. Just like any other unsupervised technique, this method is prone to long processing times and lower precision and recall percentages compared to its supervised counterpart.
• 3. Import concepts from pre-populated sources.
  • In this method, CSNs are built by converting other pre-populated semantic rich structures into concepts. Various organizations have spent great deal of resources to create domain specific thesauri and ontologies that are used for machine consumption purposes such as search and knowledge exchange. These thesauri and ontologies can be good sources of concepts that in turn can be leveraged to analyze textual contents. This approach is not only more efficient than the other two methods, it also avoids their shortcomings. Thesauri and ontologies are mostly created manually by domain experts so their quality and relevance is quit high. Converting thesauri and ontologies to CSN leverages this quality and makes it very easy for end users to use the work done by other experts. Though the third method is the easiest and most efficient, mapping thesauri and ontologies to CSNs is another challenging task. But once a mapping method is developed, it can be applied to any ontology.

Examples of widely accepted ontology languages include DAML (DARPA Agent Markup Language) and OWL. Ontolgies include two parts; one that deals with capturing definitions of terms which cover classes, subclasses, properties, restrictions, and individual objects and a second part that addresses inference and logical implications. The first part of the language (definitions) is used primarily to establish the mapping between ontologies and CSNs.

Before explaining the conversion process, it is important to highlight some of the main differences between ontologies and CSNs, which will also clarify-some of the conversion steps.

• 1. CSNs allow concepts to have “Concept Types” as a semantic property. For example the concept “Automobile” can be of the concept type “Vehicle.” Ontologies allow any number of properties and property values. During the mapping process, several options for identifying concept types from ontologies can be used, some of which are presented below.
• 2. Ontologies make distinctions between classes, subclasses, and objects, whereas in CSNs, entities are primarily concepts. For example, in an ontology, “Automobile” can be a class with a subclass of “US automobile,” and an object of that subclass can be “Ford.” In a CSN, “automobile,” “US automobile,” and “Ford” are three different concepts. The hierarchical relationship between the three entities can be preserved in a CSN, as illustrated below.
• 3. An ontology allows almost any type of relationships to exist between entities where in the CSN, the “is-a” relationship is primarily allowed. In other words, using the example above, “Ford” is-a “US automobile.” It also is-an “automobile,” and similarly “US automobile” is-an “automobile,” as shown in FIG. 3.

To illustrate the conversion process, an ontology about digital camera components will be used. This example is presented for illustration purposes only and does not limit the scope of the invention. The actual code for the digital camera ontology is presented in Appendix I. The ontology classes are: “PurchaseableItem,” “Money,” “Range,” “Viewer,” and “Window” as shown in the FIG. 4.

The PurchaseableItem class has the subclasses “Body,” “Camera,” and “Lens.” Also “Body” and “Camera” have a number of subclasses. The expanded list of classes and subclasses is shown in FIG. 5.

All ontology classes and subclasses are mapped into concepts in a CSN while preserving their hierarchical relationships. This means that the resulting CSN has the following concepts: “Purchaseable Item,” “Body,” “Body With Non Adjustable Shutter Speed,” “Camera,” “Large Format,” “SLR,” “Digital,” “Lens,” “Money,” “Range,” “Viewer,” and “Window.” These concepts are shown in the list view of FIG. 6.

Note that a “part” concept is also shown, though it was not one of the ontology classes or subclasses, but this will be explained later. Notice also that in an ontology, class and subclass names are made of a connected string (with no white spaces) as required by the ontology language specifications. In a CSN, there is no such restriction and therefore, during the conversion process, connected multiword strings are split into multiple words to provide a more user friendly interface. Bear in mind that ontologies are more machine oriented while CSNs are for human user consumption and so they are expected to be user friendly.

After identifying the concepts, the ontology-CSN conversion method identifies the concept type to associate with every concept. Several options are available to accomplish this task. The conversion mechanism may interact with the user to capture his/her preference as to which option to choose. Options can include:

• • Ontology Name: The top-level (root) element of the ontology can be used as a concept type for all concepts extracted from that ontology. This means that, for the digital camera example, every concept will be of the type “Digital Camera.”
  • Parent Concept: Parent concepts can be used as concept types. For the top most parent concept, the concept name is used as its concept type. In the above example “Purchasable Item” will be the type for concepts “Purchasable Item,” “Body,” “Camera,” and “Lens.” “Camera” will be the type for concepts “Large Format,” “SLR,” and “Digital.”
  • Top Most Class: The topmost root node for the hierarchy can be used as the concept type for all child concepts of that subtree. In the example above “Purchasable Item” will be the concept type for all concepts under its subtree.
  • Auto Concept Type: Concept types can be generated automatically using WordNet or another semantic network to identify relevant concept types.

FIG. 7 shows a sample graphical user interface that can capture a user's preference in assigning concept types.

In addition to representing class hierarchies, ontologies are capable of representing property hierarchies. One can define a property with a number of sub-properties recursively, which establishes a hierarchy. Using a ontology-CSN conversion utility, property hierarchies are converted into concept hierarchies. In the digital camera example, “part” is a property that has two subproperties; namely, “lens” and “body.” This hierarchy is also converted to a concept hierarchy with a parent concept of “part” and two child concepts of “lens” and “body.”

One of the major differences between an ontology and a CSN is inheritance. Ontologies allow downward inheritance of class properties to all its subclasses. In a CSN, concept properties may have to be explicitly defined. In other words, though concepts may be related with “is-a” relationships in a CSN, this does not necessarily imply inheriting ancestor's properties. The ontology-CSN conversion utility allows users the option to convert class properties as “child” concepts of the concept that maps to that class. If a user uses this option, properties will also be considered as child concepts of the other child concepts that map to the subclasses of the main class. To illustrate this, consider the digital camera example. The “Camera” class has “Digital” and “Large-Format” as two subclasses and “body,” “view Finder,” “lens,” and “cost” as properties. The conversion is done such that “Camera” is the parent concept and “Digital” and “Large-Format” are two of its child concepts. A user can also choose to include properties as child concepts in which case “body,” “view Finder,” “lens,” and “cost” also become child concepts of “Camera,” as illustrated in FIG. 8. Since “Digital” and “Large-Format” are subclasses of “Camera,” they inherit its properties. Regarding the CSN shown in FIG. 8, “body,” “view Finder,” “lens,” and “cost” are also child concepts of “Digital” and “Large-Format.” In other words, a user can preserve the inheritance of properties feature of ontologies when CSNs are created.

The following example, shown in Table 1, explains a part of an aviation thesaurus that deals with “air conditioning systems.” “Air cycle machines”, “ducts”, “equipment cooling fans”, heat exchangers”, “mixing valves”, “packs”, and “recirculation fans” are narrower terms with respect to “air conditioning systems”. Not only is there a great deal of redundancy in describing the relationships between terms, but users cannot use other types of criteria to group terms. When this is converted into a concept bank, as shown in Table 2, the representation is more compressed and allows the user to provide “concept types” for every concept. The types can be used for grouping and browsing purposes. In this example the user chooses to assign, whether manually or automatically (using a lexical database), the concept type “Parts” to the terms “fans” and “ducts”. The user can always browse concepts using “Part” which was not possible using thesauri.

TABLE 1
TERMID	TERM	REL	TERMID	TERM
10161	air conditioning system	NT	11230	air cycle machines
10161	air conditioning system	NT	10165	ducts
10161	air conditioning system	NT	10226	equipment cooling fans
10161	air conditioning system	NT	10500	heat exchangers
10161	air conditioning system	NT	10172	mixing valves
10161	air conditioning system	NT	1295	packs
10161	air conditioning system	NT	1302	recirculation fans
11230	air cycle machines	BT	10161	air conditioning system
10165	ducts	BT	10161	air conditioning system
10226	equipment cooling fans	BT	10161	air conditioning system
10500	heat exchangers	BT	10161	air conditioning system
10172	mixing valves	BT	10161	air conditioning system
1295	packs	BT	10161	air conditioning system
1302	recirculation fans	BT	10161	air conditioning system
11230	air cycle machines	UF	11231	ACM
11231	ACM	Use	11230	air cycle machines
10226	equipment cooling fans	UF	11208	equipment fans
11208	equipment fans	Use	10226	equipment cooling fans
10172	mixing valves	UF	10921	mix valves
10921	mix valves	Use	10172	mixing valves
1302	recirculation fans	RT	11207	fans
11207	fans	RT	1302	recirculation fans

TABLE 2
CONCEPT_TYPE	PARENT_CONCEPT	CONCEPT_TYPE	CHILD_CONCEPT
Mechanical Systems	air conditioning system	Mechanical Systems	air cycle machines
Mechanical Systems	air conditioning system	Parts	ducts
Mechanical Systems	air conditioning system	Parts	equipment cooling fans
Mechanical Systems	air conditioning system	Mechanical Systems	heat exchangers
Mechanical Systems	air conditioning system	Parts	mixing valves
Mechanical Systems	air conditioning system	Parts	packs
Mechanical Systems	air conditioning system	Parts	recirculation fans
Mechanical Systems	air cycle machines	Mechanical Systems	ACM
Parts	equipment cooling fans	Parts	equipment fans
Parts	mixing valves	Parts	mix valves
Parts	recirculation fans	Parts	fans

Due to the differences between the two representation schemes of ontologies and CSNs, automated conversion may not perfectly satisfy every end-user need. Therefore, it can be useful to have an easy to use user interface that allows users to edit the generated CSN before it is saved. Users may also want to take advantage of having their concepts in a CSN and start building more complex concepts of the basic concepts extracted from the ontology. The conversion utility could provide a GUI similar to the one presented in FIG. 9 to enable users to customize concept definitions and relationships. Internally CSNs can be stored in relational tables with an option to save or export them into other formats, such as XML, CSV, and Excel.

In an embodiment of the present invention, the system and components of the present invention described herein are implemented using well known computers, such as a computer 100 shown in FIG. 10. The computer 100 can be a special purpose device, or any commercially available and well known computer capable of performing the functions described herein, such as computers available from International Business Machines, Apple, Silicon Graphics Inc., Sun, HP, Dell, Compaq, Digital, Cray, etc.

The computer 100 includes one or more processors (also called central processing units, or CPUs), such as a processor 104. The processor 104 is connected to a communication bus 106. The computer 100 also includes a main or primary memory 108, such as random access memory (RAM). The primary memory 108 has stored therein control logic (computer software), and data.

The computer 100 also includes one or more secondary storage devices 110. The secondary storage devices 110 include, for example, a hard disk drive 112 and/or a removable storage device or drive 114. The removable storage drive 114 represents a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup, etc.

The removable storage drive 114 interacts with a removable storage unit 118. The removable storage unit 118 includes a computer useable or readable storage medium having stored therein computer software (control logic) and/or data. Removable storage unit 118 represents a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, or any other computer data storage device. The removable storage drive 114 reads from and/or writes to the removable storage unit 118 in a well known manner.

The computer 100 also includes input/output/display devices, such as display 130, keyboards, pointing devices, etc.

The computer 102 further includes a communication or network interface 124. The interface 124 enables the computer 100 to communicate with remote devices. For example, the interface 124 allows the computer 100 to communicate over communication networks or media (representing a form of a computer useable or readable medium), such as LANs, WANs, the Internet, etc. The interface 124 may interface with remote sites or networks via wired or wireless connections.

Control logic may be transmitted to and from the computer 100 via the communication medium 126. More particularly, the computer 100 may receive and transmit carrier waves (electromagnetic signals) 128 modulated with control logic via the communication medium 126.

Any apparatus or manufacture comprising a computer useable or readable medium having control logic (software) stored therein is referred to herein as a computer program product or program storage device. This includes, but is not limited to, the computer 100, the main memory 108, the hard disk 112, the removable storage unit 118 and the carrier waves modulated with control logic. Such computer program products, having control logic stored therein that, when executed by one or more data processing devices, cause such data processing devices to convert an ontology into a CSN as described herein, represent embodiments of the invention.

The invention can work with software, hardware, and/or operating system implementations other than those described herein. Any software, hardware, and operating system implementations suitable for performing the functions described herein can be used.

While some embodiments of the present invention have been described above, it should be understood that it has been presented by way of examples only and not meant to limit the invention. It will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Thus, the breadth and scope of the present invention should not be limited by the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

APPENDIX I
Digital Camera OWL Ontology
<?xml version=“1.0” encoding=“UTF-8”?>
<rdf:RDF xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#”
xmlns:owl=“http://www.w3.org/2002/07/owl#”
xmlns=“http://www.xfront.com/owl/ontologies/camera/#”
xmlns:camera=“http://www.xfront.com/owl/ontologies/camera/#”
xml:base=“http://www.xfront.com/owl/ontologies/camera/”>
<owl:Ontology rdf:about=“”>
<rdfs:comment> Camera OWL Ontology</rdfs:comment>
</owl:Ontology>
<owl:Class rdf:ID=“Money”>
<rdfs:subClassOf rdf:resource=“http://www.w3.org/2002/07/owl#Thing”/>
</owl:Class>
<owl:DatatypeProperty rdf:ID=“currency”>
<rdfs:domain rdf:resource=“#Money”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>
</owl:DatatypeProperty>
<owl:Class rdf:ID=“Range”>
<rdfs:subClassOf rdf:resource=“http://www.w3.org/2002/07/owl#Thing”/>
</owl:Class>
<owl:DatatypeProperty rdf:ID=“min”>
<rdfs:domain rdf:resource=“#Range”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#float”/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID=“max”>
<rdfs:domain rdf:resource=“#Range”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#float”/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID=“units”>
<rdfs:domain rdf:resource=“#Range”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>
</owl:DatatypeProperty>
<owl:Class rdf:ID=“Window”>
<rdfs:subClassOf rdf:resource=“http://www.w3.org/2002/07/owl#Thing”/>
</owl:Class>
<camera:Window rdf:ID=“ThroughTheLens”/>
<camera:Window rdf:ID=”WindowOnTopOfCamera”/>
<owl:Class rdf:ID=“Viewer”>
<owl:oneOf rdf:parseType=“Collection”>
<camera:Window rdf:about=“#ThroughTheLens”/>
<camera:Window rdf:about=“#WindowOnTopOfCamera”/>
</owl:oneOf>
</owl:Class>
<owl:Class rdf:ID=“PurchaseableItem”>
<rdfs:subClassOf rdf:resource=“http://www.w3.org/2002/07/owl#Thing”/>
</owl:Class>
<owl:ObjectProperty rdf:ID=“cost”>
<rdfs:domain rdf:resource=“#PurchaseableItem”/>
<rdfs:range rdf:resource=“#Money”/>
</owl:ObjectProperty>
<owl:Class rdf:ID=“Body”>
<rdfs:subClassOf rdf:resource=“#PurchaseableItem”/>
</owl:Class>
<owl:Class rdf:ID=“BodyWithNonAdjustableShutterSpeed”>
<owl:intersectionOf rdf:parseType=“Collection”>
<owl:Class rdf:about=“#Body”/>
<owl:Restriction>
<owl:onProperty rdf:resource=“#shutter-speed”/>
<owl:cardinality>0</owl:cardinality>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
<owl:Class rdf:ID=“Lens”>
<rdfs:subClassOf rdf:resource=“#PurchaseableItem”/>
</owl:Class>
<owl:Class rdf:ID=“Camera”>
<rdfs:subClassOf rdf:resource=“#PurchaseableItem”/>
</owl:Class>
<owl:Class rdf:ID=“SLR”>
<owl:intersectionOf rdf:parseType=“Collection”>
<owl:Class rdf:about=“#Camera”/>
<owl:Restriction>
<owl:onProperty rdf:resource=“#viewFinder”/>
<owl:hasValue rdf:resource=“#ThroughTheLens”/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
<owl:Class rdf:ID=“Large-Format”>
<rdfs:subClassOf rdf:resource=“#Camera”/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource=“#body”/>
<owl:allValuesFrom
rdf:resource=“#BodyWithNonAdjustableShutterSpeed”/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID=“Digital”>
<rdfs:subClassOf rdf:resource=“#Camera”/>
</owl:Class>
<owl:ObjectProperty rdf:ID=“part”/>
<owl:ObjectProperty rdf:ID=“lens”>
<rdfs:subPropertyOf rdf:resource=“#part”/>
<rdfs:domain rdf:resource=“#Camera”/>
<rdfs:range rdf:resource=“#Lens”/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=“body”>
<rdfs:subPropertyOf rdf:resource=“#part”/>
<rdfs:domain rdf:resource=“#Camera”/>
<rdfs:range rdf:resource=“#Body”/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID= “viewFinder”>
<rdf:type
rdf:resource=“http://www.w3.org/2002/07/owl#FunctionalProperty”/>
<rdfs:domain rdf:resovirce=“#Camera”/>
<rdfs:range rdf:resource=“#Viewer”/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID=“size”>
<rdfs:domain rdf:resource=“#Lens”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID=“aperture”>
<rdfs:domain rdf:resource=“#Lens”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>
<owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID=“compatibleWith”>
<rdfs:domain rdf:resource=“#Lens”/>
<rdfs:range rdf:resource=“#Body”/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID=“shutter-speed”>
<rdfs:domain rdf:resource=“#Body”/>
<rdfs:range rdf:resource=“#Range”/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID=“focal-length”>
<owl:equivalentProperty rdf:resource=“#size”/>
<rdfs:domain rdf:resource=“#Lens”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID=“f-stop”>
<owl:equivalentProperty rdf:resource=“#aperture”/>
<rdfs:domain rdf:resource=“#Lens”/>
<rdfs:range rdf:resource=“http://www.w3.org/2001/XMLSchema#string”/>
</owl:DatatypeProperty>
</rdf:RDF>

Appendix II: Concept Grammar

Legal Characters

• Child Concepts
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890( )/˜\″(space)
• Parent Concepts
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890(space)
• Concept Types
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890(space)
• Child Concepts text box (form concept pane in GUI)
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890( )/˜\″□,(space) Maximum Lengths
• Concept=900 characters
• Concept Types=100 characters Complex Concept Connector Patterns

The following are invalid patterns:

(NOTE: regular expressions follow summary.)

The connectors can not appear next to each other (ex. and and) (ex. and or)

(\sand|\sor|\s(((w/|pre/)|pre/)[1-9][0-9]*(˜˜[1-9][0-
9]*)?))\s+(and\s|or\s|(((w/|pre/)|pre/)[1-9][0-9]*(˜˜[1-9][0-9]*)?))\s*
\s+(and\s|or\s|(((w/|pre/)|pre/)[1-9][0-9]*(˜˜[1-9][0-
9]*)?))\s*(and|or|(((w/|pre/)|pre/)[1-9][0-9]*(˜˜[1-9][0-9]*)?))

“not” can not be directly followed by “and,” “or,” or “not”

• • \snot\s+(and|or|not)\s+ “of” may not be followed by connector
  • \sof\s+(of|and|or|((w/|pre/)[1-9][0-9]*(˜˜[1-9]*)?))\s+ Within or Pre searches may not be followed by “of”
  • ((w/|pre/)[1-9][0-9]*(˜˜[1-9][0-9]*)?)\sof\s+

All complex concepts should be contained in the following patterns:

Find all phrases with or without “˜” that contain “and” or “or”—alphanumeric words and tilde are optional

i.e. Words and/or tilda connected by “and” or “or”

• • [a-z0-9][a-z0-9]*[˜]?\s+(and|or)\s+[a-z0-9][a-z0-9]*[˜]?

Valid connection using “w/” or “pre/”

NOTE: “of” is an optional word that is ignored when used with “w/” or “pre/”

\snot\s*(\s((w/|pre/)|pre/)[1-9][0-9]*(˜˜[1-9][0-9]*)?)?\s+[a-z0-9][a-z0-9
]*[˜]?
\s*[a-z0-9][a-z0-9 ]*[˜]?\s+((w/|pre/)|pre/)[1-9][0-9]*(\sof)?(\s+[1-
9][0-9]*˜˜\s*[1-9][0-9]*\s*|\s+[a-z0-9][a-z0-9 ]*[˜]?)\s*
\s*([a-z0-9][a-z0-9 ]*[˜]?\s|[a-z0-9][a-z0-9 ]*[˜]?\s((w/|pre/)|pre/)[1-
9][0-9]*)?\s*[1-9][0-9]*˜˜\s*[1-9][0-9]*(\s[a-z0-9][a-z0-9 ]*[˜]?|\s[a-z0-9][a-z0-
9 ]*[˜]?\s((w/|pre/)|pre/)[1-9][0-9]*)?

Find patterns with “˜˜” between two numbers

• • \s+[1-9][0-9]*\s*˜˜\s*[1-9][0-9]*\s

Only alpha-numeric characters with or without a tilde are allowed in non-complex concepts.

• • [a-z0-9][a-z0-9]*[˜]

Claims

1. A method of producing a concept semantic network (CSN) from an ontology, comprising: a) converting each class, subclass, object, restriction, and property of the ontology to a concept of the CSN; and b) converting each hierarchy in the ontology to a concept hierarchy of the CSN.

2. The method of claim 1, further comprising: c) identifying a type for each concept of the CSN.

3. The method of claim 2, further comprising: d) assigning, to each concept of the CSN, its identified type.

4. The method of claim 2, wherein step c) comprises using the name of a root element of the ontology as the type for concepts of the CSN.

5. The method of claim 2, wherein step c) comprises using the name of a parent concept as the type for all concepts immediately subordinate to the parent concept.

6. The method of claim 2, wherein step c) comprises using the name of a topmost root element of each hierarchy in the CSN as the type for each concept in the hierarchy.

7. The method of claim 2, wherein step c) comprises using a semantic network to identify a type.

8. The method of claim 2, wherein step c) comprises identifying a type by receiving a user preference.

9. The method of claim 8, wherein the user preference is provided by a user through a graphical user interface.

10. The method of claim 1, wherein the hierarchies in the ontology comprise a property hierarchy.

11. The method of claim 1, wherein step a) comprises: i) converting a class in the ontology into a concept in the CSN, the concept corresponding to the class in the ontology; and ii) converting a property of the class into a child concept of the concept in the CSN.

12. The method of claim 1, wherein step a) comprises preserving, in the CSN, inherited properties in the ontology.

13. The method of claim 1, further comprising: c) receiving editing commands from a user; and d) manipulating the CSN according to the received editing commands.

14. The method of claim 13, wherein the editing commands are received through a graphical user interface.

15. A computer program product comprising a computer useable medium having control logic stored therein for causing a computer to produce a concept semantic network (CSN) from an ontology, the computer control logic comprising: first computer readable program code means for causing the computer to converting each class, subclass, object, restriction, and property of the ontology to a concept of the CSN; and second computer readable program code means for causing the computer to convert each hierarchy in the ontology to a concept hierarchy of the CSN.

16. The computer program product of claim 15, the computer control logic further comprising: third computer readable program code means for causing the computer to identify a type for each concept of the CSN.

17. The computer program product of claim 15, wherein the hierarchies in the ontology comprise a property hierarchy.

18. The computer program product of claim 15, wherein the first computer readable program code means comprises: computer readable program code means for causing the computer to convert a class in the ontology into a concept in the CSN, the concept corresponding to the class in the ontology; and computer readable program code means for causing the computer to convert a property of the class into a child concept of the concept in the CSN.

19. The computer program product of claim 15, wherein the first computer readable program code means comprises: computer readable program code means for causing the computer to preserve, in the CSN, inherited properties in the ontology.

20. The computer program product of claim 15, the computer control logic further comprising: third computer readable program code means for causing the computer to receive editing commands from a user; and fourth computer readable program code means for causing the computer to manipulate the CSN according to the received editing commands.