Semantic Media Wiki
PHP. Worth the security risk ?
Main Links
https://semantic-mediawiki.org/
Semantic MediaWiki (SMW) is a free, open-source extension to MediaWiki – the wiki software that powers Wikipedia – that lets you store and query data within the wiki's pages.
Semantic MediaWiki is also a full-fledged framework, in conjunction with many spinoff extensions, that can turn a wiki into a powerful and flexible knowledge management system.
All data created within SMW can easily be published via the Semantic Web, allowing other systems to use this data seamlessly.
http://en.wikipedia.org/wiki/Semantic_MediaWiki
https://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki
... helps to search, organise, tag, browse, evaluate, and share the wiki's content. While traditional wikis contain only text which computers can neither understand nor evaluate, SMW adds semantic annotations that allow a wiki to function as a collaborative database ...
... consider the category on Wikipedia called "1620s births"; if the information in these pages were stored using SMW, these categories could be replaced by simple semantic values, reducing the need for a complex classification system.
In addition, if semantic markup within the wiki is stored within templates, otherwise known as semantic templates, a wiki can easily gain a solid data structure. And the Semantic Forms extension lets administrators create forms for adding and editing the data within semantic templates, thus making the addition of semantic information even easier and more straightforward than using regular wiki text.
Semantic MediaWiki Bundles and Extensions
http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki
http://www.mediawiki.org/wiki/Semantic_Bundle
http://semanticweb.org/wiki/Semantic_MediaWiki
Semantic Forms and Templates
http://www.mediawiki.org/wiki/Extension:Semantic_Forms
http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Semantic_Forms_and_templates
http://semantic-mediawiki.org/wiki/Help:Semantic_templates
Mediawiki Links
http://www.mediawiki.org/wiki/MediaWiki
http://en.wikipedia.org/wiki/Category:MediaWiki_websites
http://www.mediawiki.org/wiki/Manual:SQLite
SQLite support for Mediawiki is of production quality as of MediaWiki 1.17
How to convert your Mediawiki database to SQLite? - http://kb.siteground.com/how_to_convert_your_mediawiki_database_to_sqlite/
http://www.linuxintro.org/wiki/Migrating_mediawiki_from_mysql_to_sqlite
Download vast segments of Wikipedia - http://dumps.wikimedia.org/
Bad History -> http://www.mediawiki.org/wiki/Manual:Upgrading
semanticweb.org.edu Task Force Spam Fighting ->
http://semanticweb.org/wiki/semanticweb.org-5.html
Database Design
https://www.semantic-mediawiki.org/wiki/Database_schema
https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki_database_tables#smw_nary_relations
https://www.semantic-mediawiki.org/wiki/SQLStore_update#Table_layout
https://www.semantic-mediawiki.org/wiki/Help:Architecture_guide
https://www.semantic-mediawiki.org/wiki/Help:Properties_and_types
https://www.semantic-mediawiki.org/wiki/Architecture_Tradeoffs#SMW_Triples_in_SQLStore3
https://meta.wikimedia.org/wiki/Semantic_MediaWiki/Blueprint
... As in the case of categories, relations can also be usefully organized in hierarchies. The idea is that all annotations that apply to a subrelation do also apply to its superrelations. For example, "is capital of" is a subrelation of "is located in": whenever a city is the capital of some country, the city is located within this country. Specifying a relational hierarchy allows us to get more information out of just a few annotations. The superrelations of some relation are described within the article of the relations (in the namespace "Relation:"). We propose a syntax that is similar to a typed link between relational articles, but using a special link type like "is subrelation of":
[[is subrelation of::Name of Superrelation]]
How does the MediaWiki Triple schema relate to the BottleTalk 'Quintuple' schema ?
For example, tag:workflow | rel:associated-with | tag:process | weight | 0.55 . Noting that everything in the relation table must be 100% redundant within the wiki text ( or at least extractable from it like association weights), does the 5-tuple work ? How to manage the symmetrical inverse, that is tag:process | rel:associated-with | tag:workflow | weight | 0.55 ?
https://www.semantic-mediawiki.org/wiki/SQLStore_update#Table_layout
Table layout
Here we document all database tables and related questions. Table smw_object_ids
This table is used to store integer IDs for SMWDIWikiPage objects. These objects can represent wiki pages (possibly with some external interwiki prefix), or subobjects of wiki pages. IDs are also kept for properties (identified by a wiki page) and for special properties (no wiki page).
Columns:
smw_id (integer NOT NULL KEY AUTO_INCREMENT): the integer id smw_namespace (integer NOT NULL): namespace of the wiki page smw_title (titletext NOT NULL): title of the wiki page smw_iw (interwikitext NOT NULL): interwiki prefix of the wiki page (or empty string) smw_subobject (titletext NOT NULL): name for subobjects of a page (empty string if the entry is about the page) smw_sortkey (titletext NOT NULL): string used for sorting smw_data_hash (varchar NULL): string used to store hash value of the Semantic Data for this page to compare with newly generated ones on page edits
Indexes:
smw_id: primary key smw_title,smw_namespace,smw_iw: selection by wiki page smw_title,smw_namespace,smw_iw,smw_subobject: selection by the full data stored in SMWDIWikiPage smw_sortkey: selection by sortkey (relevant, e.g., when < and > comparators are used with page-type properties in #ask queries)
There are also some special objects that are stored here. These are marked by special interwiki prefixes that cannot occur in real pages:
SMW_SQL2_SMWREDIIW: entries for wiki pages that are redirects. Otherwise, such rows are similar to normal entries for (internal) wiki pages. SMW_SQL2_SMWPREDEFIW: predefined entries, usually for predefined properties that have user-visible name (and a wiki page) SMW_SQL2_SMWINTDEFIW: predefined entries for objects that have an Id but no user-visible name (internal objects) SMW_SQL2_SMWBORDERIW: this is used in one row to mark the border between predefined ids (rows that are reserved for hardcoded ids built into SMW) and normal entries. This row is no object, but makes sure that SQL's auto increment counter is high enough to not add any objects before that marked "border".
Predefined entries for predefined properties are created on setup. SMW's internal predefined properties have fixed IDs to avoid lookups. Having them in the table is useful so that they can be found by functions that cannot not check this (e.g., statistical functions that show all properties). It is also important that no other object has the same ID, so it makes sense to occupy the space in the table. Table smw_property_ids
Similar to table smw_ids but has some new fields to store important information about that property
Columns:
prop_id (integer NOT NULL KEY AUTO_INCREMENT): the integer id prop_name (titletext NOT NULL): name of the property prop_table (titletext NOT NULL): name of the property-value table for this property (we are planning to have dedicated tables for some properties)
Indexes:
prop_id: primary key prop_title: selection by property name
Property-Value tables
Various tables store property-value pairs that are assigned to a given page. All of these tables have the following two columns:
s_id (integer): ID of the subject, that is, the page that has the value p_id (integer): ID of the property to which the value was assigned
All IDs refer to the entries in smw_object_ids. The columns have the following indexes:
s_id: selection by subject p_id: selection by property
For different types of values, there are different further columns as shown next.
SMWDINumber: smw_di_number
This table will store property-values of type SMWDINumber.
Value columns:
value: the value of the property(Datatype:varchar). sort_value: value used for sorting purpose(Datatype:double)
Indexes:
value: selection by value.
SMWDIBool: smw_di_bool
This table will store property-values of type SMWDIBool.
Value columns:
value: the value of the property(Datatype: Boolean).
SMWDITime: smw_di_time
This table will store property-values of type SMWDITime.
Value columns:
value_smwformat : the time stored as is now in smw_atts2.value_xsd column.(Datatype:string) value_timestampformat: the time stored as a SMW timestamp(used for sorting and other purposes).(Datatype: double)
Indexes:
time_timestampformat: selection by value.
SMWDIString: smw_di_string
This table will store property-values of type SMWDIString.
Value columns:
value: the value of the property as blob.(Datatype:Blob) hash_value: Hash value used for sorting and selection.(Datatype:varchar)
Indexes:
hash_value: Indexing strings by Hashing will allow effective searching and selection.
SMWDIWikiPage: smw_di_wikipage
This table stores property values of type SMWDIWikiPage. This table is also used to store "compound values". Such values are encoded as subobjects that act as "internal wiki pages", which can have further property values.
Value columns:
o_id (integer): ID of the object (value) that was assigned.(Datatype:int)
Indexes:
o_id: selection by value
SMWDIGeoCoord: smw_di_geocoord
This table stores property values of type SMWDIGeoCoord.
Value Columns:
lat (float): latitude of a coordinate lon (float): longitude of a coordinate alt (float): altitude of a coordinate
Indexes:
lat: selection by latitude lon: selection by longitude alt: selection by altitude
See Also
| Lessons Learned - Semantic MediaWiki | http://semantastic.com/pywacket/index.php/Project/Technology#toc3 |
Trends on Wikipedia This Week - https://tools.wmflabs.org/wikitrends/english-uptrends-this-week.html
