Working With MediaWiki

can dramatically reduce the amount of querying work that needs to be done. (Note the colon contained in both calls — this is necessary so that the parser function will actually be called.)
    You can display additional data for each calendar entry, just by adding more printouts to the query (like “
?Has attendees
”). And you can display all of that data via a template, using the “template=” parameter — see here .
    And you can set the color that each entry is displayed with, using the parameter “color=”. This isn’t very interesting for a simple query, where every event would be displayed as the same color, but it can become quite useful when calendars are displayed using Semantic Compound Queries — see here .
    There are more customizations possible for the calendar — you can see them all here:
https://semantic-mediawiki.org/wiki/Help:Calendar_format

Charts and graphs
    There are various formats defined in SRF that do a chart- or graph-style display:
googlebar , googlepie — bar and pie charts created via the Google ChartsAPI (behind the scenes, the code sends the numbers to Google, and gets back an image).
jplotbar , jqplotpie — bar and pie charts created via jqPlot, a JavaScript library.
graph — shows pages and the properties between them as a unordered “graph”, displayed with an image generated by the GraphViz application.
process — like the graph format, but shows a “process graph”, a specific type of graph used in workflow modeling.
    In Semantic Result Formats 1.8, a version that has not yet been released at the time of this writing, there are a large number of additional charting formats, using various JavaScript libraries:
jqplotchart — a format that will replace jqplotbar and jqplotpie. It supports the “bar” and “pie” charting options, and adds additional “line” and “donut” options.
jqplotseries — similar to jqplotchart, but intended for multiple sets of data; adds additional “bubble” and “scatter” charting options.
d3chart — allows for more unconventional chart types (treemap, bubble, etc.) using the D3 JavaScript library.
dygraphs — meant for very large data sets. It gets its main data from a CSV file, but allows for adding annotations to specific points using semantic properties. It uses the dygraphs library.
sparkline — creates “sparklines”, small inline charts meant to just show a general trend, using the jquery.sparkline library.
timeseries — aggregates pages by a date property value, using the flot library.
    Many of these charting and graphing formats are configurable — they can take parameters to set attributes such as the height and width, the chart title, the color scheme used, etc.
    Figure 18.2 Various charting formats from the Semantic Result Formats extension, using (rather pointless) sample data
    The default usage for formats like the jqPlot-based ones is to display a set of page names and a number for each, using a property of type “Number”. For instance, you could have the following:
{{#ask:[[Category:Departments]] |?Has number of employees |format=jqplotbar}}
    However, the jqPlot-based formats, and other charting formats, can also display a “distribution” instead — and this is ultimately the more important usage. For the case above, what are the chances that you’ll have a semantic property that holds an exact count of employees in each department? It’s more likely that what you’ll have semantically stored is just pages for the employees themselves, and you’ll have to count them “manually” for each department. Adding “
distribution=yes
” to the query makes it display a count of the number of pages for each value — instead of just listing the pages and their values. So you could instead have a query like:
{{#ask:[[Category:Employees]] |?Has department |format=jqplotbar |distribution=yes}}
    Though the two queries look very different, they will actually produce the same result, assuming both work.

Mapping
    Two MediaWiki extensions — Maps and Semantic Maps — provide the best mechanism for displaying coordinate-based data, and related functionality like geocoding of addresses. These two extensions were created together, and are meant to be used together — Maps can be used by itself, but Semantic Maps requires Maps. They support two mapping services at the moment: Google Maps and OpenLayers. (Another service, Yahoo! Maps, was supported at one time, but was dropped after Yahoo! itself