Semantic MediaWiki 1.6.0

Version 1.6 of Semantic MediaWiki is the next major release after SMW 1.5.6 that brings many new features, important behind-the-scenes improvements and a pile of bugfixes.

Upgrading existing installations
Note that SMW 1.6.0 has a new software dependency: the Validator extension that helps Semantic MediaWiki to validate user-provided parameters. It must be installed for SMW to work. Make sure that you include Validator prior to the inclusion of SMW in your LocalSettings.php. Do note that Validator comes bundled with SMW releases as of version 1.6.0. If you are obtaining the code via svn, you will need to get a checkout of Validator yourself.

Upgrading SMW 1.5.0 or higher
Installations of SMW 1.5.* and can be upgraded by replacing the files, and by running the database update (Special:SMWAdmin or SMW_setup.php script) as usual. Moreover, it is strongly suggested to enable the refresh process to update all data on Special:SMWAdmin. Older versions of SMW can be upgraded in the same way, but there can be more feature changes that require changes of wiki pages. See the current documentation for details on using the current version.

Do not forget to also install the extension Validator first and include it in LocalSettings.php prior to SMW with the following line of code. After that you may proceed to upgrade SMW.



Extensions for SMW versions up to 1.5.* should not be assumed to work with SMW 1.6.0 out of the box. All SMW extensions should be upgraded to versions that are compatible with SMW 1.6. Moreover, some functions changed and pages might need updates (see below). Additional remarks on upgrading older SMW versions are given below.

If not done already, it is suggested to change the inclusion of SMW in LocalSettings.php to the following as described in the installation instructions above:



Including SMW_Settings.php as in earlier versions will continue to work, but may be disabled in some future version.

The main user-visible changes in SMW 1.6.0 concern the Type namespace, the use of custom units of measurement (with custom conversion factors), and the declaration of Type:Record properties. Moreover, the support for the RAP (RAP - RDF API) was replaced by general RDF store support. Please see the documentation for details on how to configure this.

Type namespace
SMW no longer uses namespaces "Type" and "Type talk." All types are now built-in and there is no good reason to keep a namespace just for documenting them. A new special page, Special:Types, lists all the available datatypes (and the set of properties properties of the given type). This functionality replaces the Type namespace pages.

If you still want to use Type (for example to recover text from those pages), you should set $smwgHistoricTypeNamespace = true; before including SMW in LocalSettings.php. This should only be used to move old content to a better place, e.g. to the Help namespace and to remove links still pointing to it. The old namespaces will not be kept indefinitely.

Custom units
The only use of Type pages was the declaration of custom types that would allow unit conversion. The declaration of properties with custom units of measurement has changed in two ways: The internal data format of SMW has not changed for custom units, so stored data will be accessible immediately after the change.
 * 1) The type of these properties is now "Quantity" (not a "custom" type page)
 * 2) The conversion factors that used to be on the Type page are now given on the property page. So one can simply move this text (Type must be activated for this as described above).

Type:Record
The fields declaration of Record properties now refer to properties, not to types. If you have a property with has type::Record that uses a setting like has fields::Page; Number; String then you should now replace it with something like has fields::my page; my number; my string where "my page", "my number", and "my string" are properties in your wiki that have the right types. The use of properties instead of types is better since it allows custom settings beyond the datatype of a field (e.g. conversion factors).

The new method also involves internal changes in the data format, and it is not possible to make the update without temporarily loosing access to the stored data for Type:Record properties (until SMW's self repair has fixed all data entries).

Upgrading SMW 1.4.3 or lower
Users who update from SMW 1.4.0 or earlier should note that "n-ary" properties now are declared by properties of Type:Record as explained below, and that support for geographic coordinates has moved to the Semantic Maps extension. For upgrading earlier SMW versions, users should have a look at upgrade instructions released with SMW 1.5.x.

Synchronizing SMW with RDF stores
In 1.6, SMW now offers full support for synchronizing with external RDF stores. This allows users to write inline queries based on the imported data. Communication between SMW and the RDF store happens via SPARQL (1.1), so all SPARQL-capable stores should be supported. The specific support that SMW used to have for the RAP RDF store (RAP (RAP - RDF API) has been discontinued.

To configure synchronization of a single external RDF store, the following settings are needed in LocalSettings.php:



Please see the documentation for details on how to configure this.

An end to TYPEs
The Type namespace has been abolished. The set of types are now displayed by the special page Special:Types, and there are no "custom types" any longer. The conversion factors that used to be on the Type page are now given on the property page. So one can simply move this text (Type must be activated for this as described below). The internal data format of SMW has not changed for custom units, so stored data will be accessible immediately after the change.

By default, the Type namespace is gone and existing pages in this namespace can no longer be accessed. This can be changed by setting $smwgHistoricTypeNamespace = true in LocalSettings.php before including SMW.

New units and conversions
The way in which units of measurement work was changed. Datatype Number now does not accept any units, and a new datatype Quantity is used for numbers with units. Units must be declared on the Property page (not on the Type page as before). Additionally only units that have a declared conversion factor are accepted.

The 'record' built in type has changed
The declaration for properties of datatype Record has changed. Instead of a list of datatypes, the declaration now requires a list of properties that are to be used for the fields of the record. The declaration is still done with the property "has fields" as before. Properties must not be used more than once in "has fields", or the order of values will be random.

Built in properties for every supported datatype
For example, the property String is always of type String and available on all (English) wikis. This helps to keep some of the old Type:Record declarations valid.

Improved messages for semantic queries
We changed the way parameters in query printers are specified and handled using the Validator extension. This includes improvements to the parameter options in the Special:Ask GUI and better error reporting for inline queries.

New built in results format
Added UNIX-style DSV (Delimiter-separated values) result format.

Behind the scenes

 * Reworked internal data model, cleaning up and re-implementing the class "SMWDataValue" and all of its subclasses, and introducing new data item classes to handle data. The new class "SMWCompatibilityHelpers" provides temporal help for extensions that still depend on the old format and APIs.
 * Added API module (smwinfo) via which statistics about the semantic data can be obtained.
 * Added second parameter to parser function #info that allows choosing either the info or warning icon.
 * Added #smwdoc parser hook that displays a table with parameter documentation for a single specified result format.

Bugfixes
SMW 1.6 closes a number of bugs that have been identified in earlier versions. The more noteworthy ones include:
 * Fixed escaping issues in the JSON result format. A compatibility breaking change is that per property an array of values will be returned, even if there is only one.
 * Fixed PostgreSQL issues with the installation and upgrade code.

Extended translations
As usual, translations have been extended thanks to the Translatewiki.net project.