Working With MediaWiki

three options to try to pinpoint it: zoom in and click on the exact point on the map (the standard, and easiest, option); enter a more specific address in the address lookup field, and look it up again; or manually set the coordinates in the coordinates field (which would be an unlikely option).
    Figure 18.4 Semantic Maps form input for Semantic Forms, using Google Maps
    It’s worth noting that the address lookup field, below the coordinates, exists only for lookup purposes, and does not show up on the page that’s generated. So if you have a form where both the address and the coordinates are meant to be entered, the user may end up typing in the address twice.
    The SF form input types that Semantic Maps defines are “map” (which displays whatever the default mapping service is), “googlemaps” and “openlayers”.

Other visualizations and displays
    There are various other visualizations provided by Semantic Result Formats. Here are the relevant format names, and a description of each:
timeline — displays the values for a “Date” property of the queried set of pages on a scrollable, JavaScript-based horizontal timeline.
eventline — similar to the “timeline” format, but displays multiple points if any page has multiple values for the Date property.
gallery — displays a gallery of images, similar to the display of the

tag (see here ), where the images are either the actual pages being queried, or a property of the pages being queried. Instead of displaying the images as a gallery, it can also be used to display images one after another, in either an automated “slideshow” (if you add
widget=slideshow
) or a manually-scrolling “carousel” (if you add
widget=carousel
).
outline — splits up the set of queried pages by a set of properties that they have, grouping them so that the result resembles an outline.
tree — shows an outline of pages that have a hierarchical relationship with one another. The usefulness of this format is currently somewhat limited, because it requires all pages to have the same property pointing to one another; which only works for fairly generic properties, like “Located in”.
array — has a display similar to the “list” format defined in Semantic MediaWiki, but allows for more customization of the separators used between page names, and between values.
hash — similar to the “array” format, but outputs display in a format that can be directly used by the MediaWiki extension HashTables ( https://www.mediawiki.org/wiki/Extension:HashTables ).
tagcloud — shows a set of property values and their frequency, via a “tag cloud” display, where values with a higher frequency show up in a larger font. (This is similar in concept to the “distribution” option for the chart result formats, described previously.)
valuerank — similar to “tagcloud”, but simply shows the number of instances of each value, instead of changing the font size.
    Semantic Result Formats also provides some formats that are just mathematical functions, that display a single number based on some “Number” property that all the queried pages hold. The mathematical formats in SRF are min , max , average , median , sum and product . You can probably guess what each of these do, based on their names.
    As with graphing formats, there are a variety of other result formats that were added in Semantic Result Formats 1.8. The nature of these formats may still be in flux, but here is the current list, and their descriptions:
eventcalendar — similar to the “calendar” format, but uses the FullCalendar JavaScript library to display a calendar, instead of HTML, which can make for a slicker user experience.
filtered — shows “filters” for one or more of the printed-out properties, where a filter is a set of checkboxes for all the possible values for that property, letting the user filter the results. It’s similar in basic concept to the Semantic Drilldown extension ( see here ), but it uses JavaScript instead of PHP to display results — which means that it runs faster, though it may not be able to deal as well with a large number of pages.
listwidget — splits up results into pages, with a clickable table of contents at the top — the most common use is to split up results by alphabetically, by the first letter of their name.
pagewidget — intended to be a generic format for breaking up results into pages of display. It currently only supports one interface: