User:ChristianKl/Draft:Principles for Property Proposals

Languages

While the property proposal template allows you to enter multiple labels in multiple languages, the English label is the most important. The English label is going to be used as the basis of translations to other languages. Given that most international databases have English labels for the terms of their controlled vocabularies, it's important to analyse how our naming choices interplay with their naming choices, to avoid confusion where different databases call the same thing differently. Every property proposal should have an English description, this allows the most users to understand the proposed property and later allow users to directly translate the description into other languages.

The label of the property

Labels for authority control properties

As a default the name of an authority control property ends in "ID". If you think that for a specific property another name is more appropriate, please state your reasoning of why another label would be better explicitly.

Labels for non-authority control properties

In many domains of knowledge there are existing naming conventions. As a default, it's good to strive to use existing naming conventions. If you want to have a fast property creation, it's useful to do research of the prior art for the property you propose and explicitly list that prior art in the property discussion.

One way to do this research is to ask at the Opendata.Stackexchange whether the experts on the website know about relevant prior art (example request). Depending on the subject matter other stackexchange websites might also come in handy. Linked Open Vocabularies by Open Knowledge International is useful website to research general naming in other ontologies.

The description of the property

Descriptions for authority control properties

1. If the label of the property contains an abbreviation, the description should list the full name.
2. If the authority control property get's issued by an organisation, the name of that organization should be in the description.
3. The canonical naming sceme is "identifier for ..." Describing the same thing the same way is useful for making Wikidata easier to understand. Whenever we deviate from the basic form, we should do so with explicit reasons.

Descriptions for non-authority control properties

The goal of a description is to define the property well enough that there's a shared understanding about what the property is supposed to mean. While humans can often understand what's meant by looking at the context of a statement a computer that automatically deal with the underlying data has a hard time understanding the meaning of a property when the property is used in different ways. A clear definition of a property helps with preventing misunderstanding about the meaning of a property. Ideally, the description doesn't just repeat the word in the label but uses different words to explain what the label means. This is especially important given that most words have multiple meanings and the meanings don't point to the same clusters over different languages. A good description allows editors who translate the items into other languages to find the right translation.

Subject / Object

Generally we call the item on which the property is used subject (Q830077) and the value towards which a statement points the object (Q488383). This corresponds to Subject Verb Object and is the naming used in subject has role (P2868) and object has role (P3831). If a property proposal wants to derivate from that norm, the reasons for the derivation should be made explicit.

When do we need a property?

Need for a new authority control property

As a rule of thumb the database towards which a new authority control property points should have at least 1000 values. In special cases, there can also be a need that warrents an authority control property with fewer values, but that need should be explicitely described in the proposal. Generally, it's expected that the entries in the database are accessible via a formatter URL (P1630). In cases where the data is not accessible via an URL it's often better to use pairs such as catalog code (P528) and catalog (P972) or code (P3295) and encoding (P3294) to label the data.

Should we instead change the scope of an existing property?

In many cases we have existing properties that describe something similar. While it produces problems to narrow the scope of an existing property if the property is already used in the ways it current scope allows, widening the scope of a property doesn't come with the same problems.

Widening the scope of an existing property should be preceded by a discussion on the talk page of the property. In that discussion all the participants of the property discussion that lead to the creation of the property and WikiProjects related to the property should be pinged.

The direction of the property

If an item has a lot of statements it takes longer to load the item via the web-interface. The cost of making an edit to an item also scales proportional to the size of the item as the database has to create a new file everytime an item is changed and isn't just changing one line in the file. As a result properties should be structured in a way to limit the amount of statements per item.

Creating a property like location of creation (P1071) is better then creating the inverse property of "created here". A user that wants to look at the inverse property can use within Wikidata.org the relateditems-gadget that can be activated in the preferences. When accessing data from outside of Wikidata, the data user can query the reverse item via a SPARQL-query.

Examples

A property proposal should have three examples. If the item type of the property is item, all those examples should link to existing items on Wikidata.

Requesting the property creator right

Property creator rights may be requested at Wikidata:Requests for permissions. Users may self-nominate, or nominate one another; however, users should not be given this right if they do not want it, and non-self-nomination requests should be put on hold until the nominee comments accepting the nomination. The request must be open for at least 72 hours, except in the case of regranting of the right to former property creators and administrators where the reason for removal was uncontroversial or due to inactivity.

Administrators who regularly participate in property proposal discussions may add the property creator flag to the accounts of users who:

• are trusted members of the community and
• have a history of participanting in property proposal discussions in a thoughtful manner and
• have the rollbackers-right

Necessary criteria for the discussion to allow creation

1. A discussion should be open for at least 7 days for authority control properties, 14 days for other new properties given that those require more discussion to find the best semantics. 7 days for changing the scope of an existing property.
2. A property proposal should have at least one support vote before it's created that neither from the person who create the property proposal nor from the person who creates the property.
3. A property proposal should have more support votes than oppose votes.
4. When there's an oppose vote by people who regularly participate in property proposal discussions there should also be support votes by people who regularly participate with them and have shown themselves to have an informed opinion.

Closing property proposals as not done

1. If a property proposal stays open for 365 without a consensus for creation, the property proposal will be automatically closed. If there's still interest in the property a new discussion can be started pinging all participants in the old discussion.