Semantic MediaWiki with Property Clusters 2

From Dpldemo
Jump to: navigation, search
This document is part of a larger document: Semantic MediaWiki with Property Clusters



Current functionality of SMWpc

Ideally a separate namespace 'Class' should be used for articles which describe classes. The author tried this approach first but ran into some problems with the current implementation of SMW 1.0. So we use normal pages with a certain naming convention (class description articles must start with the word 'Class'). The most important thing of a class is the list of its properties. Technically this is implemented by a meta property '.prop describes' which states that a certain property can be used in conjunction with instances of a certain class. You will find this meta property in the definition of the respective Properties, not in the class definition. When viewing a class definition article you will of course see the list of its properties. That list is generated on the fly from this meta property.

In short, the following rules apply to SMWpc classes:

Defining a Class

  • Class definitions are wiki articles in the main namespace which start with 'Class ', followed by the class name.
  • Class names start with a capital, e.g. 'Class Foo'.
  • A class is described by calling a template called '.class definition'. This template expects
    • .. the class name ('Foo')
    • .. an optional color in #rrggbb notation; this color can be used to support a coloring scheme which corresponds to the classes
    • .. an optional icon file name; can be used to show icons instead of the class name where it seems appropriate (e.g. in the headline of class instances)
    • .. an optional base class name
    • .. a short decriptive text
    • .. a pass-through parameter which acts as a filter when displaying a list of instances (selection); you may assign a default value here
    • .. a pass-through parameter which acts as a view definition when displaying a list instances (projection); you may assign a default value here

Behind the scenes

The class definition template ...

  • sets the corresponding SMWpc meta properties (.class color, .class icon, .class extends, .class doc)
  • generates a navigation menu which offers the complete list of classes as navigation targets; the background color of the menu corresponds to the color of the current class
  • assigns the class article to a wiki category named 'Class'
  • produces a descriptive summary of the class which is returned as output to the user
  • produces a list of instances of the current class; this can be done in a generic way due to the reflection principles used; the filtering criteria (selection and projection) specified by the user are applied here

What you will see

The summary view produced by the '.class definition' template will contain:

  • class selection box
    • list of available classes
    • link to the category which corresponds to the class
    • link to the application model
    • links to create new properties and/or new classes
    • link to the meta model and to SMWpc documentation
    • class icon (if there is one defined)
  • instance list
    • list of selected instances
    • using the columns from the defined view
    • a small form where you can change selection and view
  • class description
    • parent hierarchy
    • all direct subclasses
    • list of all properties (with name, type, description etc.)
    • a list of properties (of other classes) which can serve as references to instances of the current class ('inbound pointers')
  • various links to ..
    • create a new instance (in classic mode and/or forms mode)
    • create an initial version of the category article which corresponds to the current class
    • object data template
    • object form
    • object lister


see Class Student

Possible extensions and enhancements

The following concepts are not implemented so far but could easily be added:

  • A meta property for the plural flection of the class name. This looks almost unnecessary in English but there are also other languages on earth.
  • A male / female variant of the class name ('actor' / 'actress') could be defined. Ideally SMWpc would be aware of a meta property '.class sex' and could apply the correct variant where appropriate
  • Classes without parent could automatically point to a common master class (may be called 'Class Class') to create a single rooted tree of all classes.
  • A class might be declared as virtual. In this case you could have no instances of such a class. If you wanted to use classes to model certain aspects of things ('Class Perishable') such a concept might be useful.
  • Also the contrary is conceivable: A class could be declared to be 'final' which would mean that you could not derive subclasses from it.
  • The list of 'incoming references' is currently calculated without consideration of inheritance.
  • It should be possible to add meta attributes (like author, number of recent views, date of last edit) to the instance list.


Current functionality of SMWpc

Property definitions are wiki articles which live in the reserved namespace 'Property:'. If they belong to the meta model their name will start with a dot.

SMWpc properties are described as follows:

Property Scope

The scope of a property allows us to make a distinction between:

  • native SMW-internal properties like 'has type' ("smw")
  • properties that relate to Semantic Forms ("sf")
  • properties that relate to Semantic Forms with personal classes ("smwpc")
  • "normal" properties that relate to the user domain ("user")

The scope of a property is defined by a meta property named .prop scope.

Property Definition

A Property is defined by using 'Template:.prop definition' which takes the property name, an optional color, an optional icon file name and a descriptive text. The template assigns meta properties named '.prop color' and '.prop icon' and '.prop doc'. Sometimes it may be useful to use small icons instead of property names. Care should be taken with colors as it is normally more than enough to establish a modest coloring scheme based on classes (and not on properties).

Assignment to a Class

Each Property should be assigned to at least one class. You can have Properties without such an assignment; but these are not recognized by SMWpc. Assigning a property to a class is done by using 'Template:.prop describes' which assigns the specified class name as value to the meta property '.prop describes'. It is possible to assign a property to several different classes. It does not make sense to assign the same property to classes where one class is an extension of the other one.

Assignment of values by templates

As said before all SMW properties are assigned by the use of templates. Normally this will be one template with the property´s name. Use the template '.prop assigned by' to specify the name of the template(s) which is (are) used to assign a value for this property. Using smore than one template allows to have alias names for properties. Thus a student could be said to 'attend' a certain university or to 'visit' it or to 'study at' the university.

Mandatory and optional Properties

A Property may be declared to be 'mandatory'. This means that for every class where it is applicable all instances must set a value for this property. The current implementation does not check this. The default is that a property can be used together with a class which it 'describes' but it need not be used. If a property can be used with more than one class it must either always be mandatory or never.

Uniqueness of Properties

A Property may be declared to be 'unique'. This means that there must be at most one value of this property for each instance. The current implementation checks this (although in a rather inefficient way). If a property can be used with more than one class it must either always be unique or never.

Deprecation of SMW Property Inheritance

It is discouraged to use SMW´s features for Property inheritance (built-in 'Property:subproperty of'). Inheritance between single properties is conceptually a little bit strange. Using SMWpc's class inheritance makes it unnecessary to use this feature.

Reference Properties

A Property can be declared to create a reference to other class instances ('Reference Properties': '.prop references'). The value of such a property is the name of an article which is an instance of the specified class. Assigning a reference property more than once to an article creates a set of references (if the model allows for that -- see 'uniqueness of properties'). It is possible to specify several different classes as possible reference targets of a property. Although this may look a little strange it sometimes may be useful.

It is possible to define a dedicated name for the inverse relation using 'Template:.prop reverse' (which sets the meta property 'Property.prop reverse'). Such names are quite useful when generating output in query results. Assuming that you have a Property named 'teaches' in your model which points from an instructor to a student you might be able to create a list which explains that certain students 'are taught by' certain instructors.

Polymorph References

Sometimes you want to use the same verb to assign different properties. A person might 'play' chess and 'play' the violin. But in your information model you will have two different properties for this (like 'plays instrument' and 'plays game'). Both property definitions will state that they are assigned by 'Template:plays'. The template in such a case has the responsibility to check the class of the referenced object and to set the correct property based on this decision (see example).

Algorithmic Redundancy

A Property can be declared to be algorithmically derived from other properties. The corresponding functionality may either be built into the query engine or the redundant properties may explicitly exist in the database. In the latter case they will typically be calculated by the template which is used to set the basic property from which the other one is derived. For example a predicate like 'is adult' could be derived from the day of birth and the current date. Algorithmic redundancy is expressed by 'Template:prop derived from' (which sets 'Property:.prop derived from').

Possible extensions and enhancements

  • A check could make sure that a property is not said to 'describe' two classes where one class is an extension of the other one.
  • For properties which are used as a reference to other class instances the target class conformance should be checked. The inheritance tree must be considered. If the target class was e.g. 'Person' a link might point to an instance of class 'Student' (assuming that Student is a subclass of Person).
  • Checking for mandatory properties should be implemented.
  • Checking for uniqueness of property assignments should be implemented in a more efficient way.
  • In some cases it might be useful to define the target class for reference properties in a generic way (like 'the same class as the source'). This may or may not include classes which are derived from the current class. What would that be good for? For instance you could define properties named 'comparable' or 'competes with' in that way. Now imagine that you write something like: Johannes Brahms is a _classical composer_. He was often _compared_ to _Anton Bruckner_. The inference engine should now suppose that 'Anton Bruckner' (although there may be no information on this object elsewhere in the wiki) is a 'classical composer'.
  • One could describe correlations between properties. Let us assume we have a property called 'Profession' and another property 'plays instrument'. We might want to have a way to express that 'conductors' often 'play an instrument' as well. In essence the SMWpc concept of classes is the description of property clusters (or correlations) but it currently only simply states that a property may be applicable to instances of a class or not. It does not say anything about the correlation of values. Currently it does not even allow to state that a certain optional property of a class becomes mandatory if another (optional) property has been set or if another property has some specific value.


Declaring an article to be an instance of an SMWpc class

SMWpc offers a template which declares a MediaWiki article to be an instance of a SMWpc class.

Manipulation of Properties

SMWpc offers a small API which is used to get and set property values. The 'set' methods do some basic checking of property assignments against the class model.

Inbound references

There is a template which returns a list of references to the current object. This is not the same as the classical "what links here" as we use the semantics of the class model instead of plain MW hyperlinks to calculate that list.


SMWpc uses the SMW Property Types as they are. The only thing we do is to add a SMWpc property called 'type built-in' which is set to 'true' if the Type belongs to the basic types of SMW.


Current functionality of SMWpc

Defining a category

SMWpc offers a one-click way to create a category for each class and it assigns each instance of the class automatically to that category. The name of the category must be the same as the class. So for 'Class Foo' you will have a 'Category:Foo'. SMWpc provides a template called '.cat definition' which is used in the category article. This template simply expects the name of the category; this is needed for technical reasons although it looks redundant; you must not use {{PAGENAME}} here.

Behind the scenes

The template displays the class description and assigns the category to a common super category called 'Class'. If the corresponding class has a parent class the category will be assigned to a correspondig super category, too. Thus the category tree will stay in sync with the inheritance structure.

What you will see

The category page will contain:

  • a statement saying that articles in this category are 'instances of' a certain SMWpc class.
  • the class description text

And, of course, you will see the standrad MediaWiki list of articles pertaining to the category.

Possible extensions and enhancements

The current design of SMWpc leaves categories mainly as they are. One could replicate certain parts of the Class article in the category article - assuming that novice users will primarily use the concept of categories. Only a simple change in ' definition' would be needed.

Meta Model

Current functionality of SMWpc

The meta model shows how existing concepts of MediaWiki and SMW are extended by SMWpc. Black color is used for MW, blue stands for SMW, red/brown color shows the additions introduced by SMWpc.

(made with Wgraph)

This is the common meta model for Semantic MediaWiki (SMW), Semantic Forms (SF) and Semantic MediaWiki with Property Clusters (SMWpc). Blue attributes and relations are part of SMW, red/brown attributes and relations belong to SMWpc. The green color stands for the user´s document and magenta is the color for SF.

Possible extensions and enhancements

Maybe one could allow multiple inheritance. But it makes things quite complicated. So this concept was intentionally left out.

Application Model

Current functionality of SMWpc

As application grow over time it is important to always have a consistent view of the current state. SMWpc uses a graph generator to automatically produce a diagram of the Classes and their Properties. In addition it produces a table view.

In analogy to UML we use the following layout conventions:

  • Classes are represented by rectangular boxes
    • The class name is in black
    • normal properties are listed inside the box and have a '+' as prefix
  • Properties which constitute a reference to other Classes are shown as lines pointing to them.
    • the template name used to assign the underlying Property is in black
    • The Property name itself is in brown
    • the reverse name of the Property is in green
  • Inheritance is shown as dotted blue lines.

A sample model might look like this:

error (line 6, char 18 -- line 6, char 75, EXPECT_ARGUMENT): color must be of type #000000 .. #ffffff or:
error : unexpected end of file
  1: graph "class model" . {
  2:   layout_algorithm = dfs
  3:  nodetype legend { bordercolor white color white level 0 font helvR10 }
  4:  nodetype * { font helvO12 color lightyellow bordercolor darkyellow align left }
  5:  edgetype * { font helvO10 textwidth 25 }
  6: node 'Freshman' { label "'''Freshman'''\f13" href 'Class Freshman' color #[[.class color::*]]}} }
  7:   node 'Game' { label "'''Game'''\f13" href 'Class Game' color #[[.class color::*]]}} }
  8:   node 'Location' { label "'''Location'''\f13" href 'Class Location' color #[[.class color::*]]}} }
  9:   node 'Musical Instrument' { label "'''Musical Instrument'''\f13" href 'Class Musical Instrument' color #[[.class color::*]]}} }
 10:   node 'Person' { label "'''Person'''\f13" href 'Class Person' color #[[.class color::*]]}} }
 11:   node 'Student' { label "'''Student'''\f13" href 'Class Student' color #[[.class color::*]]}} }
 12:   node 'Subject' { label "'''Subject'''\f13" href 'Class Subject' color #[[.class color::*]]}} }
 13:   node 'car' { label "'''car'''\f13" href 'Class car' color #[[.class color::*]]}} }
 14:   node 'test' { label "'''test'''\f13" href 'Class test' color #[[.class color::*]]}} }
 15:   node 'vehicle' { label "'''vehicle'''\f13" href 'Class vehicle' color #[[.class color::*]]}} }
 17: {{#ask:format=template|link=none|template=.model extends| [[.class extends::+]] [[.class extends::*]]}}
 19: {{#ask:format=template|template=.model prop| [[.prop describes::+]] [[.prop describes::*]] [[.prop refers to::*]] [[.prop reverse::*]][[.prop assigned by::*]]}}
 20:  node legend { type legend label "class model for\n''''" }
 21: }
{{#ask:mainlabel=Property|sort=.prop describes|.prop describes::+.prop describes::*.prop refers to::*.prop reverse::*}}

Possible improvements:

  • mandatory properties should have a '+', optional properties should have a '?' as a symbolic hint
  • consequently, multiple properties should have twin symbols ('++' or '??')

continue reading with part 3 ..
Personal tools