Difference between revisions of "Semantic MediaWiki with Property Clusters 2"

From FollowTheScore
Jump to: navigation, search
(→‎Current functionality of SMWpc)
(→‎What you will see)
Line 37: Line 37:
 
** link to the category which corresponds to the class
 
** link to the category which corresponds to the class
 
** link to the application model
 
** link to the application model
 +
** links to create new properties and/or new classes
 
** link to the meta model and to SMWpc documentation
 
** link to the meta model and to SMWpc documentation
 
* instance list
 
* instance list

Revision as of 22:12, 26 March 2008

Classes

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
  • 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

Example

see Class Student

Possible extensions and enhancements

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

  • A 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

template to set the parent category and show the short description of the class.

  • 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 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. An option to add pointers which link to one of the parent classes might be helpful.
  • It should be possible to add meta attributes (like author, number of recent views, date of last edit) to the instance list.

Properties

Current functionality of SMWpc

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

SMWpc properties are described as follows:

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).

Assigment 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 ceratin 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 wher it is applicable all instances must set a value for this property. The current implementation does not checks this. The default is that a property can be used together with a class which it 'describes' but it need not be used.

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).

Flag for SMW built-in Properties

  • SMW has several built-in Properties (e.g. 'has type'). To distinguish them more easily from SMWpc and from application model properties we use a specific meta property called '.prop built-in'.

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 little bit strange. Using SMWpc class inheritance makes it unnecessary to use this feature.

Reference Properties

Properties can be declared to contain a reference to 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. Currently the values of reference properties are not checked against the definition when an article is parsed. If checking was done it would also have to accept instances of derived classes as valid target objects.

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 may 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 target class of the referenced 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. Algorithmicredundancy 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
  • As desribed before the meta property '.prop references' is used to state the class of a referenced target object. In some cases it may be better to have a generic definition 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_ with _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 states that a property may be applicabel 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 assigned a value or if another property has some specific value.


Objects

SMWpc offers a template which declares a MediaWiki article to be an instance of a SMWpc class. It 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. And 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.

Types

SMWpc uses the SMW Property Types as they are.

Categories

Current functionality of SMWpc

Defining a category

SMWpc offers you to create a category for each class and it assigns each instance of the class 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 stays 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

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 'Template:.cat 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.

{{#wgraph:name=class meta model|thumb=80|svg| 

nodetype legend { bordercolor white color white level 0 font helvR10 }

nodetype SMWpc { color #ffeeee textcolor darkred bordercolor #ff6666}
nodetype SMW   { color #eeeeff textcolor blue    bordercolor #6666ff}
nodetype SF    { color #ffccff textcolor magenta bordercolor #ff66ff}
nodetype wiki  { color #eeeeee textcolor black   bordercolor #666666}
nodetype user  { color #eeffee textcolor black   bordercolor #66ff66 }
nodetype *     { font helvO12  align left }

edgetype SMWpc { textcolor darkred   color red        }
edgetype SMW   { textcolor blue      color blue       }
edgetype user  { textcolor darkred   color darkgreen  }
edgetype wiki  { textcolor black     color black      }
edgetype *     { font helvO10 textwidth 25}

node Property {label 'Property
* display units
* imported from
* provides service
\f09* .prop scope
* .prop reverse
* .prop doc
* .prop mandatory
* .prop unique
* .prop icon
* .prop color' href 'Special:Properties' textwidth 30 type SMW}
node Form     {label 'Form' href 'Special:Forms' type SF}
node Field    {label 'Field' type SF}
node Type     {label 'Type
* allows value
* corresponds to
\f09* .type built-in' href 'Special:Types' textwidth 30 type SMW}
node Template {horizontal_order 10 type wiki}
node ObjForm  {label 'Object Template\n(~data template of SF)' horizontal_order 15 type SMWpc}
node Category {horizontal_order 20 level 2 type wiki }
node Class    {label 'Class
* .class color
* .class icon
+ .class doc' horizontal_order 5 type SMWpc}
node Article  {label 'Article
\f01* equivalent URI' color lightgreen textwidth 30 type user}
edge Class    Category {label 'corresponds to' linestyle dotted type SMWPc}

backedge Property Template {label '.prop assigned by
(1..n)'  type SMWpc }
backedge Property Class    {label '.prop refers to
(0..1)'    type SMWpc }
backedge Property Class    {label '.prop describes
(1..n)'    type SMWpc }
backedge Property Property {label '.prop derived from
(0..1)' type SMWpc }
backedge Property Property {label 'subproperty of'               type SMW   }
    edge Category Form     {label 'has default form'             type SF    }
    edge ObjForm  Form     {label 'works together with'          type SMWpc }
nearedge Field    Form     {label 'is part of'                   type SF    }
nearedge Field    Property {label 'represents'                   type SF    }
backedge Class    Class    {label '.class extends
(0..1)'     type SMWpc }
    edge Property Type     {label 'has type'                     type SMW   }
    edge Article  Template {label 'uses templates to assign\nproperties individually' linestyle dotted type user }
    edge Article  ObjForm  {label 'uses template to\ndescribe the whole object' linestyle dotted type user }
nearedge ObjForm  Template {label 'uses template to assign properties' type SMWpc }
nearedge ObjForm  Category {label 'assigns article to\na category' type SMWpc }
    edge Article  Class    {label '.obj is a
(0..1)'    type user }
    edge Article  Category {label 'automatically becomes member\nof a category which corresponds\nto the Class' linestyle dotted type user }
    edge Category Category {label 'is part of'                       type wiki }
    edge Article  Property {label 'is annotated with properties according to the templates' type SMW }

splines yes

}} 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 models will 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 ppointing to them.
    • the template name used to assign the underlying Property is in black
    • The Property 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:

{{#wgraph:name=class model|thumb=60|svg| 

layout_algorithm = dfs
nodetype legend { bordercolor white color white level 0 font helvR10 }
nodetype * { font helvO12 color lightyellow bordercolor darkyellow align left }
edgetype * { font helvO10 textwidth 25 }

{{#replace: 

 node 'Freshman' { label "Freshman\f13" href 'Class Freshman' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Freshman.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'Game' { label "Game\f13" href 'Class Game' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Game.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'Location' { label "Location\f13" href 'Class Location' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Location.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'Musical Instrument' { label "Musical Instrument\f13" href 'Class Musical Instrument' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Musical Instrument.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'Person' { label "Person\f13" href 'Class Person' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Person.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'Student' { label "Student\f13" href 'Class Student' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Student.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'Subject' { label "Subject\f13" href 'Class Subject' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class Subject.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'test' { label "test\f13" href 'Class test' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class test.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'vehicle' { label "vehicle\f13" href 'Class vehicle' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class vehicle.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }
 node 'car' { label "car\f13" href 'Class car' color #{{#vardefine:x|{{#replace:{{#ask:format=list|Class car.class color::*}}|/^[^\]]*\]\] */|}}}}{{#var:x}} }

{{#ask:format=template|link=none|template=.model extends| .class extends::+ .class extends::*}}

{{#ask:format=template|template=.model prop| .prop describes::+ .prop describes::* .prop refers to::* .prop reverse::*.prop assigned by::*}} |/(..SMW::o[fn]f?..)/|}} 

node legend { type legend label "class model for\nfollowthescore.org/dpldemo" }

}} {{#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 '?'
  • multiple properties should have twin symbols ('++' or '??')


Retrieved from "http://followthescore.org/dpldemo/index.php?title=Semantic_MediaWiki_with_Property_Clusters_2&oldid=10267"