Semantic Web

OWL

I think it depend on which ontology language you are using. Typically, OWL is used to create ontology. And there are algorithms for each type of OWL

Protege's plug-in OWL Viz

Protege, the ontology editor and knowledge acquisition system, has a plug-in which is used to visualize ontologies. Since some time now, the plug-in is installed with the Protege system. There is a problem though. The plug-in, OWL Viz is dependent on the graph visualization software Graphviz, which needs to be installed separately (can be downloaded here). If it is not installed to it's standard location, then Protege need to be pointed to it. That is done on Windows as following:

1. File->Preferences
2. Click on the Tab OWL Viz
3. Under General Options set the Dot Application Path to dot.exe (in Graphviz's bin folder).

How to visualize an ontology

Finding a tool to visualize an ontology's structure is what this challenge is all about. It should be as simple and intuitive as possible, and, if possible, free of charge. It should be able to handle at least one of the standard ontology standards (e.g. OWL).

Semantic contact information in HTML

When writing HTML-documents, it’s quite common to provide some contact information in the document. The same is true for whole websites, where you typically have some dedicated page containing detailed contact information. People nowadays understand that it can be vital for their businesses to use structued ways to describe their offerings and profiles and „beeing found“ is a key aspect to success in electronic business. One aspect of this, clearly is contacting information. To my knowledge, the usual way of providing this information is the addess-tag of HTML. The address tag was originally dedicated to specifiy the owner of single document but in real life it’s often used for the markup of the „virtual phonebook entry“ of a whole site. While Dublin Core (and meta tags like DC.creator and DC.subject) is more and more used to provide metadata concerning the copyright of individual documents, I look for a future-proof and simple way for the markup of contact information for a whole website. The requirements are rather simple: It should provide far more semantical meaning as the old address tag (which has no further refinement of contacting information then beeing an address) but it should be as simple and straight-forward as the address tag.

defined classes in Protege

There are two ways to create a defined class: Use the graphical method (less expressible), or use the text box (more expressible). The graphical method is intuitive, so only the syntactical method will be defined here.

The Protégé tutorial shows how the definitions (restrictions) are made by adding to the superclasses of the class. I’ve added the equivalent classes instead, and found that it works just as well.
When clicking on the plus sign next to equivalent classes or superclasses a window pops up with four tabs: Class expression editor, asserted class hierarchy, object restriction editor and data restriction editor. In the class expression editor there is a text box, in which the classes can be defined with a special syntax.

There are several kinds of restrictions: some (existential, meaning it has to be related to at least one), only (universal, meaning it has to be related to all), min (define the minimal amount of related individuals), max (define the maximal amount of related individuals), exactly (define the exact amount of related individuals) and value (define the related individual).

In this example scenario there are the classes: Car, Truck, LargeMotor, MiddleMotor and SmallMotor.
The object properties: isIn (is in the car or truck)
If one would want to define a class which only contains individuals which are in cars: isIn some Car
Individuals with are in cars or trucks: hasA some (LargeMotor or MiddleMotor)
Individuals which are in a Rolls Royce phantom: isIn value rollsRoycePhantom
Individuals which are in exactly 2 cars: isIn exactly 2 Cars

Taggings:

Creating defined classes in Protege

The named classes in Protege are the classes which one integrates into the ontology (taxonomy) manually. These classes' superclasses are defined during their creation. The members (individuals) and subclasses of these classes have to be added manually. Defined classes, also called restrictions, define which individuals are elements of this class. A reasoner can automatically classify them as well a show relationships (superclasses, subclasses) to other classes in the ontology.

Using WSMT

Yes, Protege is the most widespread tool, I guess, but I personally do not like it, at least you should find the version you like most, because in its case the last doens't mean the best.While I was working at STI, I was using their ontology modelling tool - WSMT. It is open-source, http://www.sourceforge.net/projects/wsmt  

It allows to model in several ontology languages(WSML, OWL) and use several reasoners. Moreover, it allows to visualize the ontology. With Protege it was a bit difficult. Here is nore information about WSMT and some tutorials: http://wiki.sti2.at/index.php?title=WSMT_Tutorials

Taggings:

Protégé

One (if not the first ) tool to give a try is Protégé http://protege.stanford.edu/
with quite some history (implying a certain maturity level) and authored by knowledgable folks at stanford university.
It is free, open source, in java, supports various representation formats (like frames, OWL, RDF). it provides means for extensibility, which is alredy used by quite a few plugins (eg for visualizing, reasoning).

Semantic MediaWiki

Multiple solutions were proposed how to extend Wiki systems with the ability to manage semantic annotation.
One which managed it to production state is the Semantic MediaWiki http://semantic-mediawiki.org/

One dedicated wiki-system employing SMW being
http://semanticweb.org/

SMW is a free extension to the widely used (standard) MediaWiki system. It strikes by it's simplicity.
The basic concepts of semantic modelling (RDF) are mapped to elements of the wiki system as follows:

  • Page = Resource (or Subject in a PL statement)
  • Named Link = Property (or Predicate)
  • Linked Page = Resource (or Object)

Together forming one RDF-Statement.
The only real (and very intuitive) addition (change in syntax) being the Named Link allowing to describe the kind of relation between the subject and the object, the predicate name being constrained by a controlled vocabulary.
Thus there is no need, for new input-elements or significant changes in the editing syntax.
One drawback is the fact, that on one page only statements with the topic of the Page being the Subject can be constructed. But eliminating this constraint, while probably not much too complicated on the editing side, would impose a serious complexity problems both for operation on the data and human understanding of the data structure, thus leaving us with this trade-off between expressivity and complexity.

Semantic annotation in collaborative content systems (like wiki)

Collaborative content systems accumulated in short time a huge amount of good quality well lectured data, being in some cases a real alternative to traditional lexicons. The natural next step is the wish to exploit this human language data programmatically, allow the "machine" to understand the data, make it machine accessible. Although some information can be extracted with the general approaches of usual information extraction from web data, enriching the texts with some kind of semantic annotation would certainly lead to a new level of utility. This annotation shall be done manually by the editors. One important constraint is thus surely ease of use (simple editing, simple syntax), which is arguably one important factor for the sucess of wiki systems and in general an seamless integration in the existing system should be envisaged, so that the user isn't required to learn to much new or readapt to a change environment. This structured information, which will be inputted by the user in some simple syntax, has to be extractible and convertible to standard formats, particularly RDF (Resource Description Framework). Third step is to provide this information as a data service.

Pages

Subscribe to Semantic Web