IT:MiniGeek

From Stiki

Jump to: navigation, search

This page gives a detailed proposal for a data model for miniatures on Geekdō.

The data model suggested here is sufficiently complex and could contain so much information that I recommend that it be created as a new subdomain of Geekdō. This then avoids the problems of handling some miniatures on BGG (eg Warhammer 40,000), some on RPGG (eg Dungeons & Dragons), some on both (eg Inquisitor), and some on neither (eg Ziterdes).

Summary of new concepts:

  • [Components]: a new level of data object that is required for miniatures and that does not fit into the current Geekdō data model. These have practical applications in other subdomains too.
  • [Groups]: a new type of [family] that allows users to view all linked objects that are part of a nested hierarchy of [groups].
  • [Settings] to be global [families] that can link objects from any of the Geekdō subdomains.
  • [Models]: a way for users to specify the exact assembled figures in their collections.
  • Trade values: a method to let users value miniatures, and an algorithm for automatic system-generated weighted mean values.

Contents

Introduction

Key purposes of the proposed product:

  • To be an expert database of information regarding miniatures.
  • To allow users to track their miniature collections in a way that meets the majority of their needs.
  • To facilitate trades between users (this also generates some revenue for the site).


Data Model

The Attributes section for each table listed here is hidden by default. Click on the [show] link on the right of the page in order to see them. Any fields in those sections marked with an asterisk (*) are required at the time of data submission.

[Components]

This is the lowest level of object (the most granular; the highest level of detail). A single [component] represents an individual element that is used to construct a model (barring conversions for which a consumer has themselves cut up a component).

A [component] is a new data type that does not currently exist on Geekdō. It is absolutely required for miniatures, as components are the base object. They can be mixed from different [miniature items] to form [models], and are often collected and traded independently of the [miniature items] from which they originate. Further, an individual [component] may be packaged in various different ways by a manufacturer to form different [miniature items].

If [components] are introduced to Geekdō they could be retroactively rolled out to existing subdomains (although obviously with different attributes). For example:

  • Users often wish to trade just some components of games.
  • [Components] can be used to list separate information about individual objects that make up boxed sets for any of BGG/RPGG/VGG.
  • [Components] can be used to store information about individual articles that make up a single magazine [thing].
  • Some board games and role-playing games come bundled with miniatures, in which case those [things] can link to a miniature [component].

[Sprues]

[Sprues] are a special type of [component]. They are elementary objects in that they are single pieces sold by manufacturers, but they are specifically designed to be cut up into separate components. Because [sprues] are just a special case of [components] they should use the same underlying table in the database.

Attributes are exactly as per [components] above. If and only if a [component] has a non-blank "components" attribute then it is defined to be a [sprue]. A [sprue] should have two or more [components]. It should be possible to link one [sprue] to multiple copies of the same [component] (for those sprues that include several identical components).

[Miniature items]

A [miniature item] is a type of [thing]. It is a single package that is sold by a manufacturer.

  • Some [miniature items] will be individual figures consisting of one or more [components] (and/or [sprues]).
  • Some [miniature items] will be sets of figures consisting of many [components].

Note that some manufacturers may also sell loose individual [components]. For the purposes of the database, these are not considered to be additional [miniature items].

[Miniature versions]

These are [versions] for the [things] that are [miniature items]. These [versions] are sued in the same way as they are currently used in RPGG and BGG.

Other [things]

There are important related [things] that are not miniatures which we will want to include in the database. For a list of these including descriptions, see the example data below (the first [properties] table listed relates to [miniature categories]). A collector will want to be able to track any of these.

Each of these [things] may belong to [families]. Some relevant items are already listed on BGG and RPGG (such as earlier issues of White Dwarf magazine).

Attributes for [books], [periodicals], and [flyers] are as per [RPG items]. [Podcasts] are currently under discussion for RPGG, and should have the same attributes across the various {{Geekdo]}} subdomains. Attributes for painting and modelling materials to be determined following confirmation of which objects are in scope (I anticipate that these will have separate fields depending on whether they are [paints], [brushes], [tools], or [modelling materials]).

New [properties]

[Properties] are short lists used to classify items by various types. I propose the following new [properties] in order to populate the fields for the various data objects:

  • [Miniature category]: the various types of miniatures and related objects to be stored on the database.
  • [Material]: the various substances with which a component may be manufactured.
  • [Base]: the ways in which a model may be based.
  • [Release]: the availability of the model from the manufacturer.
  • [Packaging]: the kinds of bags and boxes in which miniatures are sold.

For sample tables for each of the above, see the example data below.

[Groups]

These are [family] data objects. I've just called them groups in order to distinguish them, and because they will be far more numerous with greater levels of hierarchy than the [families] used on BGG and RPGG. [Groups] can contain any of: [components], [miniature items], and other [groups].

One key piece of (new) useful functionality is to be able to see the list of linked objects either for just the current level (i.e. show just those objects linked directly to this [group]) or at all lower levels too (i.e. show those objects linked directly to this [group], and linked to [groups] linked to this [group], and linked to [groups] that are linked to [groups] that are linked to this [group], and so on all the way down). This is required because of the wide number of ways in which miniatures are categorised, and because collectors often limit themselves to just certain subsets of miniatures.

[Groups] should only exist to the extent that [miniature items] or [components] can be separately assigned as members of these [groups]. As an example there are miniatures for many of Games Workshop's Space Marine chapters but not all of them; so whilst there would be a need for a "Dark Angels" [group], there would be no need for a "Sons of Medusa" [group].

[Series]

A [family] data object as per RPGG. A [series] should be used only where there is a clear numbering or naming of [miniature items] by the manufacturer.

[Settings]

A [family] data object as per RPGG.

Ideally any [setting] should be accessible from all Geekdō subdomains rather than just RPGG as it currently stands. This requires a [family] to be able to hold [things] of different types; it is not clear whether the existing data model supports this possibility or not.

[Miniature genres]

A [family] data object as per RPGG.

Values will include the following (and almost certainly more):

  • Fantasy
  • Ancients
  • Medieval
  • Napoleonic
  • WWI
  • WWII
  • Modern
  • Science fiction

[Games]

Any individual [miniature item] is usually intended for use with one or more games. [Game] is a shorthand used here to refer to any of these games. In practice a [game] could be any [family] or [thing] (or possibly even [version]?) from either BGG or RPGG. Typically miniatures are produced for wargames, role-playing games, or board games.

[Models]

A [model] is an individual instance of a complete miniature figure.

  • Many (probably most) [models] (especially older models) will have just one [component].
  • Some [models] will have multiple [components]. For example a typical humanoid figure may consist of three components: a body (head to feet), a left arm, and a right arm; this provides the consumer with some flexibility in posing the model, and allows the publisher to produce more interesting moulds by allowing for more complex poses.
  • Some [models] will have duplicate [components]. For example a motorcycle might consist of a chassis, two identical wheels, and further components for the rider and accessories. Another example might be a tree that consists of a base, a trunk, and several identical branches.

A crucial fact is that an individual user may construct a model using any variety of components. Therefore a [model] is not a permanent database entry in the core part of the site. Instead it is a temporary data construct that is stored as part of the information in a user's collection.

A user should have full control over the information about one of their [models], including the option of deleting the entry from the database. It should also be possible to transfer a [model] data object from one user to another.

[Units]/[Forces]/[Armies]

These data structures act as ways that users can organise their [models].

  • A [model] may belong to any number of [units], [forces] or [armies].
  • A [unit] belongs to at least one [force] and/or [army].
  • A [force] belongs to at leat one [army].

Just as [models] only exist as part of a user's collection, so too do these data structures.


Table links

A summary of the links between core data tables:

From Table Count Count To Table
Game 1+ 0+ Group
Group 0+ 0+ Group
Game 1 0+ Miniature Item
Group 0-1 1+ Miniature Item
Item 1 1+ Version
Miniature Item 1 1+ [fixed/variable] Sprue/Component
Sprue 0-1 2+ [fixed] Component

A summary of the links between user collection tables:

From Table Count Count To Table
Army   1+ Force/Unit/Model
Army 1+ 0+ Force
Army 0+ 0+ Unit
Army 0+ 0+ Model
Force   1+ Unit/Model
Force 0+ 0+ Unit
Force 0+ 0+ Model
Army/Force 1+   Unit
Unit 0+ 1+ Model
Model 0-1 1+ Component [in user's collection]



Trade values

Users enter a mean value that they think is appropriate for the particular [version] or [component]. Below is an algorithm to calculate a weighted average value, where weights per user are based on how close to the unweighted mean their valuations tend to be.

The calculation of the weighted mean value (WMV) is a three-stage process:

Alternative idea

As a completely separate way to handle [component] and [miniature item] values, users could list a bid and/or offer price. The bid price is the price at which they are willing to purchase an item. The offer price is the price at which they are willing to buy an item. This is sufficient information for Geekdō to then act as an exchange to automatically match parties for trades (extracting a marginal fee of course) and therefore acting exactly like a stock exchange. Mid-prices and price histories and so on can all be easily extrapolated from this simple set of data.

I honestly believe that this piece of functionality, if introduced and properly handled, could make Geekdō more popular than eBay for trading miniatures (and could easily be extended to BGG/RPGG/VGG). Matching trade partners given bid and offer prices is such an amazingly useful piece of functionality. My mind is reeling with the possibilities that this would unleash (slightly limited by the constraints of non-instant transactions since these are tangible assets being traded).


Notes to self on further thoughts that need refining

  • Conversions
  • Models made from a mix of components
  • Self-sculpted components and models
  • Painters?
  • Scale? If so, at [component] level? What about models that can be used at various scales (eg Forge World's Large Chaos Spawn)? And models that have no specified scale? Perhaps best not to include this. Instead a [game] has a scale, and the models for that game are implied to have that scale. We explicitly require dimensions, and this is sufficient.
  • Get publishers on board - contact in advance - Games Workshop, Rackham, Grenadier...
  • Contact expert user groups in advance - CollectingCitadelMiniatures...
  • Is [designer] required / is [sculptor] sufficient? Any prior design work by other individuals can be noted in a [description] or [more info] field. Could be handled by a GeekList that is added to the artist's [person] page as a [weblink]. For example: John Blanche.
  • Should [sculptor] be at [component] level and inherited by [miniature item]? Should [publisher] be at [miniature item] level and inherited by [component]?
  • Models: allow custom combinations. Therefore only exists as an individual conglomeration of components that belongs to a [user]. No "previously owned"; handle that through [miniature items] and [components] instead. Allow transfer to another [user].
  • Customisable hierarchal grouping of [models]? Into [units] and [armies]... Printable rosters.
  • Can a [game] be a [version]? Consider how objects are currently stored on BGG.
  • Genre can be handled by the overarching [games]. Should it be separately listed at a [miniature item] level? If not, we need additional entries for "(generic fantasy)", "(generic science fiction)", and so on.
  • What attributes to split between [miniature items] and [miniature versions]?
  • Add a section for variations on the proposed data model
Retrieved from "http://stelio.net/stiki/IT:MiniGeek"
Personal tools
Navigation