Difference between revisions of "SemanticMediaWiki"

From Wiki4Intranet
Jump to: navigation, search
(Quality note)
 
(2 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
|created=2006-08-22
 
|created=2006-08-22
 
|included=2012-12-12
 
|included=2012-12-12
|included version=1.8.x
+
|included version=2.3.x
|status=forked
+
|status=fork
 
|useful=maybe
 
|useful=maybe
 
}}
 
}}
Line 13: Line 13:
 
[[Category:Incomplete extension descriptions]]
 
[[Category:Incomplete extension descriptions]]
  
== Quality note ==
+
== Usage note ==
  
* SemanticMediaWiki is definitely a piece of bloated software, and it seems it becomes more bloated in new versions — 1.9 will contain a lot of refactoring, adding composer support and multiple library dependencies, DI framework, unit tests (a religion which leads to refucking all the code)… and almost no new features.
+
It seems almost nobody uses SMW for its original ideas (semantic web, rdf, ontologies and etc) — everyone just uses it to be able to add properties to pages, create something like «object model», create Semantic Forms, use #ask queries as something like «sql» for objects and turn MediaWiki into a CMS.
* It seems almost nobody uses SMW for its original ideas (semantic web, rdf, ontologies and etc) — everyone just uses it to be able to add properties to pages, create something like «object model» using Wiki-programming and get something like «sql» using ask queries, which are ugly and inconvenient to use. Or even just to be able to use Forms. And the properties are global, so you’ll also end up modeling «object classes» from scratch if you begin creating an object model.
+
* Summary: avoid massive usage of SMW if you can. Usually it leads to very ugly efforts of «wiki-programming». If you still have to use SMW, check out our improvements to it (see below).
+
  
== Our improvements ==
+
But SMW is far from ideal for this purpose — it’s not that fast, properties are global (i.e. not specific to an object class), and the #ask query language is not so convenient… Usually it ends up with a massive amount of very ugly «Wiki-programming» efforts.
  
* Query optimizer: identical subqueries are executed only once (for example, in <tt><nowiki><q>a OR b</q> <q>c OR d <q>a OR b</q></q></nowiki></tt> the «a OR b» part will be executed only once), identical terms are removed from conjunctions/disjunctions («a AND a», «a OR a» == just a)
+
So, avoid massive usage of SMW if you can. If you still have to use it, check our improvements to it (see below).
* Conjunction-of-disjunctions execution bug fixed: in the original SMW, «(a OR b) AND (c OR d)» query was not executed at all! (test case: <tt><nowiki>{{#ask: <q>[[A::B]] OR [[C::D]]</q> <q>[[E::F]] OR [[G::H]]</q> | format=debug }}</nowiki></tt>). Patch sent to github: https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/19
+
 
* Negation operator support: syntax is <tt><nowiki>{{#ask: [[prop::val]] !<q>...subquery...</q> }}</nowiki></tt> or just <tt><nowiki>{{#ask: [[prop::val]] ![[prop2::val2]] }}</nowiki></tt>. Patch sent to github: https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/20
+
== Our improvements ==
* Disable forced type-named properties: in the original SMW, data type aliases also have an unpleasant side-effect: if a property name matches the alias of some data type (for example «Telephone number») — the property will have that data type forced and you cannot override it. Patch sent to github: https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/21
+
* Automatic refresh of all pages with semantic queries on any property update — in the original SMW you have to manually refresh it every time. Of course this can lead to frequent cache flushes — even the queries that don’t use the updated property are flushed — but at least the user always gets correct query results.
+
  
Rough estimate for getting all this in trunk: never, or not any time soon. You have to push authors very hard to be able to submit something in SMW. I don’t feel that I want to spend my time on it.
+
* Query optimizer: identical subqueries are executed only once (for example, in <tt><nowiki><q>a OR b</q> <q>c OR d <q>a OR b</q></q></nowiki></tt> the «a OR b» part will be executed only once), identical terms are removed from conjunctions/disjunctions («a AND a», «a OR a» == just «a»).
 +
* Negation operator support: syntax is <tt><nowiki>{{#ask: [[prop::val]] !<q>...subquery...</q> }}</nowiki></tt> or just <tt><nowiki>{{#ask: [[prop::val]] ![[prop2::val2]] }}</nowiki></tt>.
 +
* Permission hook support (allows to use SMW, for example, with [[IntraACL]]).
 +
* Fixed PostgreSQL support (may be merged into the next original release, 2.4).
 +
* Fixed localised boolean value names (yes/no).
 +
* Support for selection of property chains (<nowiki>{{#ask: ... | ?Prop1.Prop2}}</nowiki>) and sorting on them (<nowiki>{{#ask: ... | sort=Prop1.Prop2}}</nowiki>).
 +
* LEFT JOINs on sort fields — pages without sort property do not disappear from query results anymore.
 +
* Fixed fatal error when handling empty <nowiki><info /></nowiki> tag on wiki pages.
 +
* Support long titles (up to 767 bytes), like in our [[Mediawiki4Intranet]] core patch.
 +
* Bugfix for rebuildData.php: it didn’t accept --conf option.
 +
* Internal bugfix for ParserData which allows other extensions to retrieve page SemanticData before saving it.
 +
* Bugfix for count API requests.
 +
* Add predefined properties for major modification date (i.e. the timestamp of latest non-minor revision), major revision comment, last revision comment. All are optional and must be enabled in $smwgPageSpecialProperties to work.

Latest revision as of 17:45, 29 June 2016

SemanticMediaWiki is a MediaWiki extension.

Status for Mediawiki4Intranet distribution:

  • Inclusion date: 2012-12-12
  • Included version: 2.3.x
  • Improvement status: Forked in MediaWiki4Intranet with major improvements

Usage note

It seems almost nobody uses SMW for its original ideas (semantic web, rdf, ontologies and etc) — everyone just uses it to be able to add properties to pages, create something like «object model», create Semantic Forms, use #ask queries as something like «sql» for objects and turn MediaWiki into a CMS.

But SMW is far from ideal for this purpose — it’s not that fast, properties are global (i.e. not specific to an object class), and the #ask query language is not so convenient… Usually it ends up with a massive amount of very ugly «Wiki-programming» efforts.

So, avoid massive usage of SMW if you can. If you still have to use it, check our improvements to it (see below).

Our improvements

  • Query optimizer: identical subqueries are executed only once (for example, in <q>a OR b</q> <q>c OR d <q>a OR b</q></q> the «a OR b» part will be executed only once), identical terms are removed from conjunctions/disjunctions («a AND a», «a OR a» == just «a»).
  • Negation operator support: syntax is {{#ask: [[prop::val]] !<q>...subquery...</q> }} or just {{#ask: [[prop::val]] ![[prop2::val2]] }}.
  • Permission hook support (allows to use SMW, for example, with IntraACL).
  • Fixed PostgreSQL support (may be merged into the next original release, 2.4).
  • Fixed localised boolean value names (yes/no).
  • Support for selection of property chains ({{#ask: ... | ?Prop1.Prop2}}) and sorting on them ({{#ask: ... | sort=Prop1.Prop2}}).
  • LEFT JOINs on sort fields — pages without sort property do not disappear from query results anymore.
  • Fixed fatal error when handling empty <info /> tag on wiki pages.
  • Support long titles (up to 767 bytes), like in our Mediawiki4Intranet core patch.
  • Bugfix for rebuildData.php: it didn’t accept --conf option.
  • Internal bugfix for ParserData which allows other extensions to retrieve page SemanticData before saving it.
  • Bugfix for count API requests.
  • Add predefined properties for major modification date (i.e. the timestamp of latest non-minor revision), major revision comment, last revision comment. All are optional and must be enabled in $smwgPageSpecialProperties to work.