wiki:Notes/SemanticMediawiki

Semantic Media Wiki

PHP. Worth the security risk ?

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

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

PythonMarkup#MediawikiMarkup

Last modified 7 months ago Last modified on 09/05/2018 07:12:10 PM