Content Management
DRAFT - DRAFT - DRAFT
the objective of this page is to explain how the content of the wiki page could be structured using Semantic for Mediawiki (SMW) to build a scalable and object-based wiki (for search and relation-building aspects) and still keeping the freedom for authors to create their content. There needs to be a trade-off to be found between freedom and structure.
Why Semantic for Mediawiki?
SMW allows to have a form-based creation of objects. the form asks the users some key information then create the corresponding page and render the entered information in a consistent way, assign the category accordingly etc.
Because the page created is based on a template, changing the template modifies the instantiation of the created pages.
SMW also allows to create dynamic queries inside pages. The content will be modified based on other pages content. this is a powerful manner to make references to other pages without doing manual maintenance of the page. A practical and basic example would be that if the query below was inserted a page creation (a template being called by a form):
{{#ask:
[[FoundIn.Page::{{PAGENAME}}]]
| format=list
| link=all
}}
The page content will update itself to list all other pages that refer to this new page. There are much more granular type of queries to be done (including on categories) which then become really handy.
General Principles and Naming Convention
SMW uses multiple notions. They are key to be used properly for good use.
| Object | Usage | Naming Convention | Example |
|---|---|---|---|
| Page | the core component of the wiki and what readers are consuming. By default, there is no hierarchical structure of pages - and categories are the better way for structuring a wiki | each Word is start with a capital letter. Spaces and brackets are allowed. mutiple words are recommended to be separated by a space (mediawiki uses underscore instead of %20 for URL)
Title Case |
Nissan Leaf (2010-2017) |
| Category | the categories are part of the generic Mediawiki structure. its reflects a categorization or labeling of pages. Categories can be nested which are useful to reflect a structure of "component of" and for "is a subtype of". Multiple categories can be assigned to page, hence it can provide multiple view at once. A dedicated section of this page will cover their aspects.
There are cases where it is not obvious whether a property or a category makes more sense. one does not prevent the other, by the way. |
as the wiki already as categories created and they use naming similar to Page, the categories will further be named the same way.
Title Case |
Battery
Connector |
| Property | SMW specific - it defines a relation between 2 objects, or assign an attribute to an object. the target (called Special:Types) can be a list, another page. When defining a property, it would make sense to refer to a specific category of object (for instance, FoundIn would be referring to a Vehicle or a Component), but the type of object we can refer to are Pages, Numbers, Date,... nothing to do with category. | UpperCamelCase.DestinationObjectType or UpperCamelCase.DestinationAttributeType | FoundIn.Page
HasWeight.Qty |
| Template | SMW specific - defines which properties values shall be defined at the creation of an object. Not all pages must be created using templates, but objects which have relations between themselves are best created using templates. | the template name shall refer to a corresponding category name, and the template shall enforce that category at page creation.
T/UpperCamelCase.OutputFormat |
T/Connector.Infobox
T/Battery.PlainText |
| Form | SMW specific - A Form is an helper for the author to create a templated object. The form allows to create a consistent visual structure to pages | F/UpperCamelCase - the Form refers to a corresponding Template, but the output format will not be referred to in the form name.
A form can also call multiple templates - in such case its name will refer to the first one |
F/Connector
F/Battery |
Categories
At the time of writing, the following category structure exist: (in the absence of CategoryTree extension, doing my best to represent it):
| Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|
| Basics | |||
| Parts | Inverter | ||
| Motor | |||
| Battery | |||
| Charger | |||
| DC/DC | |||
| HVJB (High Voltage Junction Box) | |||
| Contactor | |||
| PCB | |||
| CAN | |||
| LIN | |||
| ISA Shunt | |||
| Accelerator Pedals and Position Sensors | |||
| Gearbox | |||
| Gear Selectors | |||
| Power Steering | |||
| HVAC | |||
| Heater Air | |||
| Heater Coolant | |||
| Water Pumps | |||
| AC Compressor | |||
| Adapter | |||
| Arduino | |||
| ESP32 | |||
| ESP8266 | |||
| ZombieVerter | |||
| VCU | |||
| OEM Manufacturers | BMW | ||
| Bosch | |||
| Chevrolet | |||
| Ford | |||
| Honda | |||
| Hyundai | |||
| Isabellenhütte | |||
| Land Rover | |||
| Lexus | |||
| Mercedes-Benz | |||
| MG | |||
| Mitsubishi | |||
| Nissan | |||
| Opel | |||
| Peugeot | |||
| Renault | |||
| Tesla | |||
| Toyota | |||
| VAG (Volkswagen Audi Group) | VW | ||
| Vauxhall | |||
| Volvo | |||
| Charging Systems | ChaDeMo | Chademo with Zombieverter | |
| CCS | |||
| Charge Ports | |||
| Rapid Charging | |||
| Fast Charging | |||
| Conversions | Mechanical | Parts | |
| OpenInverter Projects | |||
| OEM Repurposing | |||
| Obsolete | |||
| Accessories | |||
| Education | |||
| Errors | |||
| Fix Links | |||
| Imported Vocabulary | |||
| Pages with Broken File Links | |||
| Pages with Ignored Display Titles | |||
| Request for Review | |||
| Troubleshoot | |||
| Webasto |
I am proposing to shuffle the categories in such structure - italic names are to be created
| Top level | first level | second level | third level |
|---|---|---|---|
| Manufacturer | |||