Searching and Ranking Ontologies on the Semantic Web Edward Thomas (Aberdeen) Harith Alani (Southampton) Derek Sleeman (Aberdeen) Christopher Brewster (Sheffield) KCAP-05 Workshop Ontology Management: Searching, Selection, Ranking, and Segmentation Third International Conference on Knowledge Capture Banff, Canada

Other Ontology Search engines Google offers a powerful search engine; but for ontological information, does not provide good visualization & does not allow the user to make some important distinctions (see later) Google offers a powerful search engine; but for ontological information, does not provide good visualization & does not allow the user to make some important distinctions (see later) Swoogle allows one to search for classes or properties, but does not allow one to search for structural features (eg animal class with cat within 2 links) Swoogle allows one to search for classes or properties, but does not allow one to search for structural features (eg animal class with cat within 2 links)

Specification for OntoSearch We implemented a basis system with Google as its heart & then had users evaluate it. Heres a summary of their requirements: We implemented a basis system with Google as its heart & then had users evaluate it. Heres a summary of their requirements: –The ability to specify the types of file(s) to be returned (OWL, RDFS, all) –The ability to specify the types of entities to be matched by each keyword (concept, attribute, values, comments, all) –The ability to specify partial or exact matches on entities. –Sub-graph matching eg concept animal with concept pig within 3 links; concepts with particular attributes

Implementation The heart of the enhanced system is a repository of previously run Queries and responses provided by Google; this info is date stamped The heart of the enhanced system is a repository of previously run Queries and responses provided by Google; this info is date stamped (Non-structural) User queries are broken down into keywords & Google queries are constructed for these keywords (Non-structural) User queries are broken down into keywords & Google queries are constructed for these keywords Before each query is run, the Repository is checked to see if that query has been run less than D days ago; Before each query is run, the Repository is checked to see if that query has been run less than D days ago; If the query is a new one or the query was run > D days ago then the query is run on Google & the results are indexed as above. If the query is a new one or the query was run > D days ago then the query is run on Google & the results are indexed as above. Then the original user query is answered using the (updated) repository Then the original user query is answered using the (updated) repository Finally, Results are returned to the user Finally, Results are returned to the user OntoSearch is implemented in Java Servlets OntoSearch is implemented in Java Servlets [Repository uses Berkeley DB2 with optimised indexes for better performance than SQL based Triple Stores] [Repository uses Berkeley DB2 with optimised indexes for better performance than SQL based Triple Stores]

OntoSearch OntoSearch currently has two main interfaces OntoSearch currently has two main interfaces –Keyword based class match search Simple interface allows matching on class and property names Simple interface allows matching on class and property names –A query based structure search

Example Query Query syntax is similar to the N/Triples representation: This Query contains four conditions which must be met in a matching document: contains an element $1 which has type #Ontology contains an element $1 which has title Ontology contains an element $2 which has type #Class contains an element $2 which has a comment containing programmer Keywords (Ontology, programmer) are extracted from this query and used to query Google in the same way as would be done for the standard search, and any results which come back are downloaded and added to the repository.

Ontology Ranking Current ranking systems (Swoogle, OntoKhoj) rely on an ontologys popularity to determine its rank Current ranking systems (Swoogle, OntoKhoj) rely on an ontologys popularity to determine its rank –The large number of FOAF and RSS files on the Semantic Web produce a large bias in favour of ontologies used by these representations –The relatively small number of other Semantic Web Documents does not constitute a large enough data set to make reliable judgements No consideration is given as to how a matching concept is represented in an ontology No consideration is given as to how a matching concept is represented in an ontology –Searching for an ontology to describe a student may match a well connected ontology which covers the whole academic domain –The popularity of a general ontology is likely to be higher than a specific ontology which better covers the particular concepts searched for

AKTive Rank AKTive Rank uses four measures to determine an Ontologys rank (detail given in the paper) AKTive Rank uses four measures to determine an Ontologys rank (detail given in the paper) –Class Match Measure –Centrality Measure –Density Measure –Semantic Similarity Measure These measures are weighted and summed to give an overall AKTive Rank score These measures are weighted and summed to give an overall AKTive Rank score

Example OntoSearch was queried in class match mode for ontologies matching the concept student and university OntoSearch was queried in class match mode for ontologies matching the concept student and university 8 ontologies were returned, 2 failed basic tests; so 6 were analysed by the AKTive Rank system 8 ontologies were returned, 2 failed basic tests; so 6 were analysed by the AKTive Rank system –dan - –ita - –univ-bench - –swportal - akt_ontology_LITE_inst.owl –ka - –russia2 - karlsruhe.de/WBS/meh/foam/ontologies/russia2.owl Weighted sums were calculated for each ontology, and the sums ranked Weighted sums were calculated for each ontology, and the sums ranked

Results Rank AKTiveRank Score SSM DEM CMM CEM sw- portal kaitadan Russia 2 univ- bench WeightingNameOntologiesMeasure

Future Work OntoSearch OntoSearch –More advanced query language will be implemented –Additional Web Services / APIs –Additional sources of ontologies (including private ontologies) will need to be integrated –Better integration with AKTive Rank –Additional visualisation tools are being developed AKTive Rank AKTive Rank –The parameters used in the AKTive Rank process need to be reconsidered following further evaluations by knowledge Engineers of the ontologies recommended. –Existing RDF query languages are inadequate for dealing with graph queries; incorporate a better graph querying system, such as JUNG.

Thank You Any Questions? Work done as part of the AKT consortium Christopher Brewster Computer Science Dept. Uni. of Sheffield, Sheffield, UK Derek Sleeman Computer Science Dept. Aberdeen University Aberdeen, UK Harith Alani Dept. of Electronics and Computer Science Uni. of Southampton Southampton, UK Edward Thomas Computer Science Dept. Aberdeen University Aberdeen, UK