Category Archives: SKOS

Semantic Modelling part 2: “Red Ball” explained

So.. worked yourself through all the Red Ball modelling examples of my previous post? Now what..which one to choose? Let’s systematically discuss them all. To help yourself reading and comparing, open the modeling examples page and read on. To explain some terms I use I have made links to a thesaurus that is running on my demo machine (see also this post). This thesaurus cites from the Protege OWL tutorial.

To understand the difference between every option, remember that OWL was developed to create knowledge systems that are understood by humans and machines.  So to verify if you have created meaningful code: imagine that you are a machine, what is documented in the code that helps you understand the concept of a Red Ball?

Option 1 just declares a class with the name RedBall. This has meaning for humans..but for a machine this could be anything as similar as “Thing2”[1]. This could still be a valid modelling approach in a situation where other concepts are already described. In OWL it is allowed to include definitions from other sources into your model. In fact, this happens all the time. This code below helps the machine understand that a RedBall is in fact a type of Ball (which is declared in the namespace) :

      a       owl:Class ;
      rdfs:subClassOf <> .

Option 2 defines RedBall as a specialisation of Ball. As a human I read it like this: a RedBall is a (kind of) Ball. So, when we know what a Ball is, we also know what a RedBall is. It is a Ball with some extra characteristics.

What does it mean in OWL[2] ? The property rdfs:subClassOf defines that (quote) if a class C is a subclass of a class C’, then all instances of C will also be instances of C’. (unquote). So when an instance of RedBall is declared, it is also an instance of Ball. Now it comes to the question: what does the machine know about a Ball? For everything that is known about a Ball will be inherited into the RedBall. And, since RedBall is a separate class, we can add extra meaning to it that is not valid for the parent class Ball.

In option 3 we created an instance of Ball with the name RedBall. An instance is different from a class because an instance is an existing thing (it is data) and a class is a conceptual thing (part of a data model – the semantic model). So we have told the machine that we have an actual Ball, and that its name is “RedBall”. As a human we now know that it has the colour Red (since this is stated in the name), but as a machine we do not know anything about RedBall except that it is an actual Ball.

For option 4 we use a construction with owl:DatatypeProperty . A datatype property assigns a value to an instance of a Thing. The value can be any xsd schema datatype, or a user defined datatype. By using a property, we are now finally starting to model with a bit more meaning. We are defining a property that can be used to add meaning to an instance of a class. In semantic web modeling you can define as many properties as you like, every property adding its bit of meaning. There are predefined properties that belong to an existing scheme (such as the RDFS scheme with the most used “rdfs:label” property, or the Dublin Core schemes) or you can specify your own. If you do create your own, remember that the property is the middle part of the RDF triple statement so it must be a verb (otherwise the statement cannot be read as natural language by humans, personally I consider this bad modelling). If a statement is modelled with a datatype property the object part cannot be further described (other than that it is of a xsd schema datatype). In our example “Red” cannot be further explained. In other words: the semantic network (graph) stops  at a datatype property.

When we model with an object property on the other hand, our option 5, we can describe what we mean by the colour red. Since by definition an object property links two instances of a class we have the opportunity to describe the subject and the object in detail.

Option 6 introduces a new schema, the SKOS schema. This schema is very useful when you want to describe the meaning of things in a simpel, yet very powerful manner. SKOS is meant for documenting thesauri and taxonomies. These are basically dictionaries (with properties such as related term, synonym, abbreviation, definition)  with generalistic relations (broader term, narrower term, related term etc.).

The SKOS scheme semantics is implemented in many inference engines. This gives you the opportunity to specify the necessary statements while the inference engine creates the logical consequence statements for you. Example: in your model you define that A skos:broader B. The inference engine will now generate B skos:narrower A for you. This saves you from a lot of data entry!

Also note that the SKOS concepts are instances  of the class skos:Concept. Instances are data. It is good practice to give data records a meaningless identifer. So  in the example I have given the  identifier the form C001 and C002. The skos:prefLabel property gives us the actual name of the instance.

The skos:narrower property describes the relation between “Ball” and “RedBall” as hierarchic. This (quote) indicates that one is in some way more general (“broader”) than the other (“narrower”) (unquote). It does not say hierarchic against which parameter! This could be anything like size, weight and indeed colour. To describe what a RedBall exactly is, and how it relates to other Things we need the power of the OWL schema.

Option 7 and 8 are two examples of OWL constructs. In OWL a Thing is assigned meaning via its properties.  These examples show how  owl:Restriction  can be used for describing (option 7) and defining (option 8) a RedBall. The difference between the two lies in the direction of the meaning of the statement. In option 7 the following is true: if something is a RedBall then it must have the value ColourRed for property hasColour and it must be of type Ball. The direction of the statement is one way. In option 8: if something hasColour ColourRed and it is a Ball then it must be a RedBall. This can be proven by an inference engine (also called a reasoner). The direction of the statement is bidirectional.

In the To Learn page of my blog are sources that give you in depth background information of the above. In particular the Protege sources and the book “Semantic Web for the Working Ontologist” by Hendler and Allemang.

[1] This must be Thing2 since Thing is the top concept of any ontology

[2] Actually, subClassOf is part of the RDF schema RDFS


Semantic Modelling part 1: “Red Ball”

In this post I discuss some of the many ways how one could create a semantic model for the concept of “a red ball” in OWL. Every solution has its pros and cons, and I will comment on that in a separate post.

Before I begin I would like to emphasize that I recommend modelling with natural language, so that a human as much as a computer can understand the code. I mean this: not: “Ball colour Red” , but instead “Ball hasColour Red”. To a machine this makes no difference, for a machine the middle of the statement just refers to the id of a property, but for a human the addition of “has” adds more meaning to the statement.

The examples increase in complexity. The RDF serialization code of the examples is Turtle (TTL).

Option 1:

Define a class RedBall.

      a       owl:Class .

 Option 2:

Define a subclass RedBall as a specialization of Ball.

      a       owl:Class .
      a       owl:Class ;
      rdfs:subClassOf :Ball .

Option 3:

Define an instance “RedBall” of class “Ball”.

      a       :Ball .

Option 4:

Work with datatype properties. Define a string datatype property “hasColour” and assign it to an instance of the class Ball. Fill the property with the value “Red”.
Note: since it is not allowed to use the same name twice in one RDF dataset I have used the name “MyBall” for the instance.

      a       owl:Class .
      a       owl:DatatypeProperty ;
      rdfs:range xsd:string .

      a       :Ball ;
      :hasColour "Red"^^xsd:string .

Option 5:

Work with object properties. Define a object property “hasColour” and assign it to the class Ball. Fill the property with the instance “RedColour” of the class “Colour”.
For this one it is neccessary to define the class “Colour”, and create an instance “RedColour”.

      a       owl:Class .
      a       owl:Class .
      a       owl:ObjectProperty .
      a       :Colour .
      a       :Ball ;
     :hasColour :RedColour .

Option 6:

Use the SKOS vocabulary. The SKOS vocabulary is a vocabulary that builds on OWL. It is meant for creating a knowledge organization system. What is a knowledge system? To really understand this one should study the SKOS reference and see what terms and relations can be modelled in that scheme, but basically it is an extended scheme for a dictionary. It allows you to document more than just “term” and “definition” (which is just a table with two columns, basically). There are also options for documenting alternative names and definitions. In addition you can make relations between terms such as “broader”, “narrower” and “related” (there are many more, but these are the most important). In SKOS one models instances.

In a SKOS scheme you can specify that a red ball is related to a ball, or more specific, that it is a narrower description of a ball:

      a       skos:Concept ;
      skos:prefLabel "Red Ball"@en .

     a       skos:Concept ;
     skos:prefLabel "Ball"@en ;
     skos:narrower :RedBall .


Option 7:

Describe a RedBall as anything that is a Ball and has only colours that are of ColourRed.

      a   owl:Class ;
           [ a       owl:Class ;
            (:Ball [ a  owl:Restriction ;
              owl:onProperty :hasColour;         
              owl:allValuesFrom :ColourRed 
              ] .

Option 8:

Defining that if something has at least one Colour “ColourRed” and it is a Ball, then it is a RedBall.

      a    owl:Class ;
           [ a       owl:Class ;
            owl:intersectionOf (
           :Ball [ a  owl:Restriction ;
                  owl:onProperty :hasColour ;
                  owl:someValuesFrom :ColourRed
              ] .

This ends the list of examples that I want to give you now. There are even more possibilities, most of them a combination of the examples given. If you’d like to share some of yours, welcome in a comment!



Publishing a SKOS vocabulary with TemaTres

If you have created a Knowledge Organisation System with SKOS and are looking for ways  to publish it you might have a look at TemaTres. This tool is so simple and yet so complete that -if you are aware of some have-to-knows..- you have a running website within hours. The application has an out-of-the-box SPARQL endpoint (!), a huge variety of export options and also options for mappings to other concept scheme’s. on top of that it has buttons that search the displayed term in well-known web sources like Google Scholar, Wikipedia, Google Books.

TemaTres is based on PHP and MySQL, so it is best to use a LAMP or WAMP server.

First of all, there ‘s the documentation..the best part of it is in you have work yourself through that. Also, the documentation is shattered around different places, amongst them the website , the sourceforge page and the creator’s home domain.

Some essential information is not available in the documentation.

  1. SKOS files that you want to import must be serialized as RDF/XML
  2. Replace any rdf:Description tags for skos:Concept tags, otherwise the import file will not be recognised at all
  3. TemaTres expects everything in the SKOS Core schema, so any rdf(s) entities are ignored. Similarly, not every SKOS property will be displayed
  4. To modify the metadata of the vocabulary afterwards, use this URL: <your tematres server/tematres/admin.php?vocabulario_id=1>
  5. The URI of your vocabulary must end with ‘/’ . This is necessary for the links to the SPARQL endpoint to work (these links are in the footer and in the metadata page of the vocabulary (to be opened in the menu..About…))