Difference between revisions of "SemanticMediaWiki"
From Wiki4Intranet
(→Our improvements) |
|||
| Line 7: | Line 7: | ||
|included=2012-12-12 | |included=2012-12-12 | ||
|included version=1.8.x | |included version=1.8.x | ||
| − | |status= | + | |status=forked |
|useful=likely | |useful=likely | ||
}} | }} | ||
{{ExtensionFromInfo|lang=en|name=SemanticMediaWiki}} | {{ExtensionFromInfo|lang=en|name=SemanticMediaWiki}} | ||
[[Category:Incomplete extension descriptions]] | [[Category:Incomplete extension descriptions]] | ||
| + | |||
| + | == Quality 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, 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» using Wiki-programming and get something like «sql» using ask queries, which are ugly and inconvenient to use. And the properties are global, so you’ll also end up modeling «object classes». | ||
| + | * 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 == | == Our improvements == | ||
| Line 20: | Line 26: | ||
* 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 | * 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. | * 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 want to do that. | ||
Revision as of 15:59, 24 December 2013
"forked" is not in the list of possible values (our, fork, fixed, backport, orig) for this property.
SemanticMediaWiki is a MediaWiki extension.
- Main purpose: Associate semantic properties with wiki pages, and various features based on it.
- Repository: https://github.com/mediawiki4intranet/SemanticMediaWiki
- Homepage: http://semantic-mediawiki.org, SemanticMediaWiki on mediawiki.org
- License: GPLv2.0+
- Created: 2006-08-22
- Our rating: May be useful (3)
Status for Mediawiki4Intranet distribution:
- Inclusion date: 2012-12-12
- Included version: 2.3.x
- Improvement status: Forked in MediaWiki4Intranet with major improvements
Quality 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, 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» using Wiki-programming and get something like «sql» using ask queries, which are ugly and inconvenient to use. And the properties are global, so you’ll also end up modeling «object classes».
- 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
- 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)
- 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: {{#ask: <q>[[A::B]] OR [[C::D]]</q> <q>[[E::F]] OR [[G::H]]</q> | format=debug }}). Patch sent to github: https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/19
- Negation operator support: syntax is {{#ask: [[prop::val]] !<q>...subquery...</q> }} or just {{#ask: [[prop::val]] ![[prop2::val2]] }}. Patch sent to github: https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/20
- 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 want to do that.
