Semantic Internal Objects

Description
There is not enough pertinent information about most bus stop amenities to warrant the creation of its own web resource page. Yet there is enough of a need for distinguishable information for amenities that needs to be machine-queried. As an example, it would be beneficial to know the relationship between the actual number of riders at a stop per trip and the number of available seats at the same stop.

Amenities ought to be considered a complex type with n-ary relations (ie, multiple associated data values), such as an amenity of type concrete bench that seats 5 people. By themselves the semantics are not fully realized & sometimes meaningless. Where SMW many-valued properties fall short (ie, in flexibility & query-ability), the Semantic Internal Objects (SIO) extension (using its #set_internal parser function) excels. For SIO, each property data type still needs to be defined.

NB: SIO defines an object (ie, page) with an automatically-generated name based on the page the property was created (eg, Bus stop 1234#1 and Bus stop 1234#2). However, when an internal object property is deleted, the number for all subsequent internal object properties from the same page changes (eg, if Bus stop 1234#1 is removed, Bus stop 1234#2 become Bus stop 1234#1). This may prove problematic if service requests are ever related directly to internal object properties by name.

Because inverse queries are not supported for internal objects (currently, support is only for Pages, internal objects technically are not), the internal object must have a property pointing back to the current bus stop. This is handled behind-the-scenes in the template definition (e.g., creating a property linking back to the bus stop). Of note, before returning query results, it would instead make sense to parse the internal object name since it does include the bus stop name in the its name (eg, check and return benches that match string 'Bus stop 1234#??' regardless of value of ??).

For versions of SMW before 1.5.2, internal-object data will unfortunately not appear when a page with #set_internal is first created - the page must be saved at least twice for the data to show up. source

Issues
It has been noted that SIO properties are repeated. This can cause misleading information. For example, bus stop times are set as internal objects and consist of an assigned trip, arrival time, departure time, and stop sequence (as well as a relationship back to the specified bus stop). This is done with the following wikitext:

However, when queried out, the results are duplicated. This can happen more than once, leading to many more values returned. The cause of this is not yet known.

Workaround
The repeated internal object properties will reset if you save the page again. Just hit edit and save; you do not need to add any information.

EDIT: Fixed as of SIO 0.6+
 * July 16, 2010 - Fix for "duplicate rows" bug; fix for when Semantic Maps is not installed; improvements to RDF export