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.

Type of Mediawiki Objects and their usage

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. Ideally, categories shall be written in plural form (because it is a grouping of x) Title Case (in plural)	Batteries Connectors
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.Qantity
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 in singular, 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

Hierarchical relationship

There are often 2 possibilities for defining relationship between objects, you can go from parent to child, or from child to parent.

In practical manner, I can define from a DC/DC that it is a component of the vehicle XYZ, or from that vehicle, that it uses the component DC/DC ABC.

On a pure conventional basis, the link will be made from child to parent. This is practical as when we describe a component (like a DC/DC), the car it belongs to is quite likely already created as a Page, but the connectors composing the DC/DC less likely so. we would then be blocked in defining the DC/DC because we cannot create the connector (or same with the CAN message it generates). In reality, we will face quite often such situation that the associated object does not exist yet. The convention is not fixing all problems.

Pages or Categories?

Categories helps grouping of similar Pages together. Quite often, we can consider a category (like BMW), but when using Properties, we cannot link them to categories. So, in such case, a Page is required. To avoid meaningless empty Pages, the following minimum information can be added:

• A dynamic query listing all pages referring to this page, (possibly organized by category)
• A button to call a form to create a component from that page (i.e. a component from BMW).
• the rest of the page must of course be editable for content creator to capture and share their knowledge.

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	transferred
Basics			x
Parts	Inverter		x
	Motor		x
	Battery		x
	Charger	Rapid Charging	x
	DC/DC		x
	HVJB (High Voltage Junction Box)		x
	Contactor		x
	PCB		x
	CAN		x
	LIN		x
	ISA Shunt		x
	Accelerator Pedals and Position Sensors		x
	Gearbox		x
	Gear Selectors		x
	Power Steering		x
	Water Pumps		x
	Arduino		x
	Adapter		x
	Thermal Management	AC Compressor	x
		Heater Coolant	x
		Heater Air	x
	HVAC	Coolant Fittings	x
		Coolant Valve	x
	ESP32		x
	ESP8266		x
	ZombieVerter		x
	VCU		x
OEM Manufacturers	BMW		x
	Bosch		x
	Chevrolet		x
	Ford		x
	Honda		x
	Hyundai		x
	Isabellenhütte		x
	Land Rover		x
	Lexus		x
	Mercedes-Benz		x
	MG		x
	Mitsubishi		x
	Nissan		x
	Opel		x
	Peugeot		x
	Renault		x
	Tesla		x
	Toyota		x
	VAG (Volkswagen Audi Group)	VW	x
	Vauxhall		x
	Volvo		x
Charging Systems	ChaDeMo	Chademo with Zombieverter	x
	CCS		x
	Charge Ports		x
	Fast Charging		x
Conversions	Mechanical	Parts	x
	OpenInverter Projects		x
	OEM Repurposing
	Obsolete
Accessories			x
Education
Request for Review			x
Troubleshoot
Webasto			x
Legalities			x

I am proposing to shuffle the categories in the following structure - bold/italic names are to be created

Manufacturers categories and structure

the structure is meant to only identifies the group of brand (as they will likely be sharing components). Therefore, if a brand leaves a group to join another, a distinct brand category must be created.

Model names (a specific category - see below) is attached to the brand related to its parent group (i.e. Opel Ampera is linked to GM, Opel Moka is linked to Stellantis). this structure gives us the flexibility to manage changing alliances/holdings over time.

Cars are being sold with different names (Opel/Vauxhall, Renault/Mitsubishi etc), therefore, while the Page Name may refer to a specific brand-model combination, the car model shall not be a category on its own.

The OEM Manufacturers shall include the groups that are delivering parts to car makers (Bosch, Magnetti Marelli etc)

Top level	Group	Brand	Note
OEM	BMW Group	BMW
		Mini
	General Motors	Chevrolet
		Opel (<2017)	the Opel Ampera was still under GM, so it is a completely different affiliation than today
	Stellantis	Opel (2017-)	the new ones
		Vauxhall
		Peugeot
		Citroen
	Toyota Motor Corporation	Toyota
		Lexus
	Hyundai Motor Group	Hyundai
		Kia
	Renault-Nissan-Mitsubishi Alliance	Mitsubishi
		Renault
		Nissan
	Ford Motor Corporation	Ford
	Tata Motors	Land Rover
		Jaguar
	VAG (Volkswagen Audi Group)	Volkswagen
		Audi
		Skoda
	Geely Holding Group	Volvo
	SAIC Motor Europe	MG
	Honda
	Bosch
	Isabellenhütte
	Mercedes-Benz
	BYD
	Tesla
	Webasto		moved under OEM Manufacturers
	TE Connectivity		build connectors (notably for BMW)
	Aptiv		build connectors (notably for Nissan) - ex Delphi (ex GM :-) )
	Molex		build connectors (notably for Tesla)
	Sumitomo		build connectors (notably for Mitsubishi)
	Hirose		build connectors (notably for Mitsubishi)
	Dilong		build chargers (at the very least)
	Eltek		build chargers (at the very least)

Parts (Components)

Top level	2nd level	3rd level	Note
Parts	Inverter
	Motor
	Brake Assist
	Battery Packs	Battery modules	this is a split of the battery category
		BMS	moved under Battery packs
		Contactor	where SBOX, VBOX and Isabellenhutte should belong. moved under battery packs
	DC/DC
	HVJB (High Voltage Junction Box)
	Accelerator Pedals and Position Sensors
	Gearbox
	Gear Selectors
	Power Steering
	Charging Systems	ChaDeMo
		CCS
		Charge Ports
		Fast Charging	moved out of charger and under charging systems
		Charger	moved under charging systems
	Thermal Management	AC Compressor
		Heater Coolant
		Heater Air
		Water Pumps
		HVAC
		Coolant Fittings
		Coolant Valve
	Connectors
	Cables
	Instruments
	Mechanical Adapters	CAD	mechanical and adapter categories to be merged as "mechanical adapters"

Software, Electronics and Protocols

Top level	2nd level	3rd level	Note
Electronics	VCU	ZombieVerter
		OpenInverter
	chipsets	ESP32
		ESP8266
	PCB	Arduino
Protocols	CAN	CANID	category to define the CAN messages
	LIN
	Ethernet

Other categories

Top level	2nd level	3rd level	Note
Basics	Tutorials		covers the necessary understanding required before envisaging a conversion project (maybe merge the 2 categories?) Tutorial to be merged with Tutorials
	Resource		merge with Introduction?
	FAQ
Conversion			ongoing and succesful conversion projects (the VCU should be a mandatory sub-category I think)
Legalities

Proposed for deletion (category, not content!)

Name	Number of Pages	Reason for request for deletion
Accessories	0	what is mandatory? What is an accessory? better consider they are parts. the category has 0 page so far
Hardware	0	better call it parts - 0 page
ISA Shunt	1	this should not be a category on its own but a page of category "connector"
Chademo with Zombieverter	0	should be part of category chademo
Request for Review	1	this seldom used
OpenInverter Projects		better have a combination of the "conversion" and the corresponding VCU category?
Introduction		merge with Resource?
DEAD	1	possibly wrongly created in the first place
Delta	1
General Tesla FAQ	1	should be a page part of category FAQ, not a category on its own.

Templates structure

the intent is that for some content that would fit a given category, an associated template and form is being created. Not all pages must be created like that, and it is quite possible that such templated pages must be created when a certain maturity level is being reached. For those selected categories, the associated object and data properties must be identified. It is likely that some will be resused throughout different type of objects (any physical component has dimension and weight for instance).

I have identified the following categories that are not created yet and which are useful (so as not to mess with any contributors' work at this stage)

- Parts/Connectors

- Parts/Cables

- Protocols/CAN/CANID

Connectors

Page Name Structure:

the name is composed of 4 components

	Mandatory	Remarks
Manufacturer	yes
Family	yes
Model	no
header/Plug	yes	header: connects to a physical component plug: connects to a cable

Manufacturer - family - specific model - header/plug

• Examples:
  • Aptiv - SHIELDPACK HV APEX280 SB - Plug

Infobox content:

PropertyName	Label (friendly name)	Associated Object or Data	single/multiple	Mandatory/Optional	Comments
HasImage.Page	Image	Page for in the File: namespace	single	Optional	Multiple images can be used for an object, but having one that serves inot the infobox, which can tell also be used for visual searches (imagine you do not know what type of connector you have, you can look at a visual gallery to find out which one you have and the associated relevant information) The image display will be constrained in the form for a given size.
IsProducedBy.Page	Manufacturer	Page	single	Optional	Link the component to its manufacturer
UsedIn.Page	Used in	Page	multiple	Optional	allow to link the parent components/vehicles which are using this component
IsMatedWith.Page	Mating connector	Page	single	Optional	When available, define which connector is used to connect to it.
IsHighVoltage.Boolean	High Voltage	Boolean	single	Mandatory	defines if HV or not
HasInterlock.Boolean	Interlock Present	Boolean	single	Mandatory	defines if interlock pins are present or not
HasColour.Text	Main colour	Text	single	Mandatory	describe the most prevalent colour of the connector. it can be useful for narrowing down searches. the list of colour should be constrained to avoid having "Deep sea blue" or "amethist" type of colours...
HasReference.Text	References	Text	multiple	optional
HasTerminals.Number	number of terminals (pins)	Number	single	Mandatory	number of pins or holes on the connectors, WITHOUT counting the interlock
HasDatasheet.URL	Link to Datasheet	URL	single	optional