Wikidata:Creating a property proposal

Here are some guidelines you should follow before or while proposing a property.

External identifier properties

Please intend on creating a Mix'n'Match catalog after the property you are proposing is created so that your property is used beyond the examples you provided. If you can't create a Mix'n'match or import values, don't bother proposing the property as it will likely just sit unused. Using described at URL (P973) instead may be an alternative.

Entity properties

Determining the relationship direction

It has become a de-facto practice in Wikidata to have only a single property to describe a relationship in a one direction. For example, a musical release (Q2031291) is related to its release group (Q108346082) using release of (P9831) on the musical release (Q2031291) item. However, an inverse "has release" property does not exist to relate a release group (Q108346082) with its musical release (Q2031291). This is done so that:

1. Users don't have to add the inverse property
2. Space in the database does not need to be consumed for the inverse property
3. The property and its inverse do not need to be consistently checked to make sure they are present on both entities

However, this does have the downside that users do not see the inverse property on the other entity when they are viewing it on Wikidata or reading it from another data format (like RDF). So, users then have to query for it in order to find it which then may put more strain on the query service. Scripts like MediaWiki:Gadget-relateditems.js have helped solve this problem by allowing users to see inverse relationships.

Usually if a property expresses some parent->child relationship, the property usually points from the child to the parent (child->parent), as in the case of release of (P9831).

Specifying the domain and range

It is extremely important you specify the domain and range of your property, or at least have a strong and clear conveyance of them in the case that the Wikidata ontology or constraint system is not able to ensure the domain and range are always met. This is to make sure that your property isn't used outside of your original usage purpose, which may deteriorate data quality. Properties should aim to be as specific as possible in the type of relationship they are making so that users later don't have to move relationships a non-specific property makes to more-specific properties.