PhD Work: Design
Contents
- A Domain Ontology for a NLQS
- Dataflow for a NLQS
- Visualizing Ontologies
- Ontology and RDF Data Files Map
- NLP Systems
- An Ontology for Representing User-Controlled Thesauruses
- Datastores
Entries
<< Previous Entry | Next Entry >>
3. Visualizing Ontologies
To complement the new ontology some example class instantiations have been written for the classes define within MMO V1.1. All the XML data files currently uploaded in my Triplestore can be found here.
It is all well and good having an ontology that is sound and has a good domain coverage but if you do not know how to use it then it is wasted. Visualizing ontologies is something that many researchers have been working on for a while. As the reasons that researchers have for needing visualization tools vary, There are quite a number of them about. I have experimented using Protege, SWOOP, RDF Gravity and several other visualizers. Protege can be used to spefically visualize ontologies using its "ontovis" tab, whereas RDF Gravity is only designed for visualizing the raw RDF of an ontology. None of them have been able to generated an output that I have found more useful than just using RAP, the RDF API for PHP that can output a colour coded list of all the triples in any file I provide it with. Therefore I have designed a informal diagramming format to represent ontologies in. Below is My Music Ontology (MMO) represented using this diagramming format.
As you can see from the diagram all classes are represented inside ovals and properties linking two classes are represented with an arrow from the subject of the RDF triple to the object. This diagramming style is quite similar to that used for representing Meta Content Framework (MCF) the precursor to RDF. There are some subtle differences however:
- My diagramming format is designed specifically for ontologies, therefore it only represents structure not data, classes not instances.
- Unlike the MCF diagram, the properties classes are not drawn. This is done for the MCF diagram because it needs to explictly define the domain and range of its properties, as properties can link data and not just structure togther. Without explicit definition it would be impossible to be certain what type of object a certain bit of data was. My diagramming format implicitly defines the domain and range because they are the subject and object that is linked by that property.
- The majority of property links in my diagramming format are properties defined within the namespece. Take the diagram for MMO above, rdfs:subClassOf, dc:title are clearly from the RDF Schema and Dublin Core namespaces. The reason rdfs:subClassOf is included is to simplify the diagram. If two super classes are the subject and object of a property relationship then by rdfs:subClassOf it is unnecessary to draw property relationships between all the two sets of subclasses. dc:title is included because although it not defined property in the namespace, part of the rdfs:subClassOf restriction in class that is in the namespace states that it must have one dc:title relationship. Therefore it is useful to display this in the diagram to ensure the user includes this relationship in any RDF data they generate.
I have written a quick key to help understand the various symbols in a diagram, that can be viewed by clicking here.