Wikidata:Property proposal/Generic

From Wikidata
Jump to: navigation, search
Shortcut: WD:PP/GEN

Property proposal: Generic Authority control Person Organization Event
Place Space Economics Transportation Natural science
Creative work References Term Unsorted Sister projects

This page is for the proposal of new properties.

Before proposing a property
  1. Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:AllPages.
  2. Check if the property is already pending or has been rejected.
  3. Check if you can give it similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data automatically can be transferred. See wd:Infoboxes task force for suggestions.
  4. Select the right datatype for the Property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Creation can be done after 1 week by a property creator or an administrator.
  2. See steps when creating properties.

Add a request

This page is archived, currently at Archive 22.

To add a request, you should use this form:

=== {{TranslateThis
| de = <!-- PROPERTY NAME IN German (optional) -->
| fr = <!-- PROPERTY NAME IN French (optional) -->
<!-- |xx = property names in some other languages -->
}} ===
{{Property documentation
|status                 = <!--leave this empty-->
|description            = {{TranslateThis
  | en = put English description for property here, e.g. same as in the infobox documentation
|infobox parameter      = put Wikipedia infobox parameters here, if existing; ex: "population" in [[:en:template:infobox settlement]]
|datatype               = put datatype here (item, string, media, coordinate, monolingual text, multilingual text, time, URL, number)
|domain                 = types of items that may bear this property; preferably use Q templates, as specialized as possible, or text. ''e.g.'' {{Q|6999}} (astronomical object), {{Q|12136}} (disease), {{Q|11436}} (aircraft), and more generally {{Q|2221906}} (place), {{Q|43229}} (organization), {{Q|1656682}} (event), {{Q|386724}} (creative work), etc.  Special values (having specialized validation schemes): Persons, Taxons
|allowed values         = type of linked items (Q template or text), list or range of allowed values, string pattern...
|suggested values       = (deprecated)
|source                 = external reference, Wikipedia list article (either infobox or source)
|example                = sample items that would use that property, with proposed values; example: {{Q|1}} => {{Q|2}}
|filter                 = (sample: 7 digit number can be validated with edit filter [[Special:AbuseFilter/17]])
|robot and gadget jobs  = Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.)
|proposed by            = ~~~
(Add your motivation for this property here.) ~~~~

For a list of infobox parameters, you might want to use table format:

{{List of properties/Header}}

{{List of properties/Row|id=
|title          = audio
|type           = media
|qualifier      =
|description    = Commons sound file
|example-subject= Q187 <!-- Il Canto degli Italiani -->
|example-object = Inno di Mameli instrumental.ogg


For blank forms, see Property documentation and List of properties/Row

Property proposal: Generic Authority control Person Organization Event
Place Space Economics Transportation Natural science
Creative work References Term Unsorted Sister projects

infobox's main topic[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: primary topic of the subject template or infobox

Motivation. To avoid confusion with other "main topic" properties. See: Property_talk:P301#template_main_topic--Micru (talk) 14:59, 23 June 2014 (UTC)

Symbol support vote.svg Support --- Jura 19:42, 24 June 2014 (UTC)
Pictogram voting question.svg Question: The phrasing of the label is similar to things that have a 1-to-1 relationship on Wikidata. I think this may require a many-to-1 relationship, though. Would this property allow multiple types of templates to point to the same topic item as long as they all have the same primary subject of the template? If so, then this is probably OK. But, if this is supposed to be a 1-template-per-subject relationship, we're going to have trouble. There are multiple kinds of topic templates: For example, English Wikipedia has a topic-specific template that goes at the top of an article or section: Category:Infobox templates (Q6154820); then two types of topic templates that usually go at the bottom of the article: Category:Navigational boxes (Q5607945) (almost always topic-specific) and Category:Succession templates (Q6804414) (which have topic-specific versions). Then there are the well-used Category:External link templates (Q5612193). Then there are templates that substitute specific names, like Category:Taxon authority templates (Q8832383). Other projects may have different ones: I don't know if the template styles that are important on English Wikipedia are the important ones on other projects. And that's not counting Category:Userboxes (Q8307767), which — at least on English Wikipedia — is mostly idiotic except for the very important Category:Language user templates (Q5824304) and a couple of other topics. --Closeapple (talk) 15:19, 1 July 2014 (UTC)
Closeapple, This would be used as category's main topic (P301). If a property has more than one topic, it is possible to add an exception on the constraint check. If a template doesn't have a main topic, that is fine too.--Micru (talk) 15:28, 1 July 2014 (UTC)
But unlike categories, multiple types of templates for a single subject are pretty frequent, particularly for broad topics like government offices, types of places, etc. All the topic templates other than in Category:Navigational boxes (Q5607945) would probably be exceptions. To be clear: I'm not opposing a multiple-to-1 relationship. I just think it needs to be treated that way, not as an exception: If we use {{Constraint:Unique value}} on this, the exception list is going to be huge. (And if someone makes an inverse property to pair with this property, it should be made clear that {{Constraint:Single value}} is not appropriate for that property either.) --Closeapple (talk) 16:24, 1 July 2014 (UTC)
I understand, it would be hard to model all combinations. Let's focus on the easiest cases first and let's see how far we can get. Maybe we need more properties (like "template combines topics" or others).--Micru (talk) 16:50, 1 July 2014 (UTC)
Pictogram voting question.svg Question would not it be more convenient the other way around ? Such as
< Roads > Wikipedia infobox search < Infobox:Roads >
 ? I think a specific property is not absurd here. Eventually it seems also interesting to code a generic infobox template, which looks the class of the item in wikidata and find in the superclasses the relevant infoboxes template. TomT0m (talk) 19:25, 1 July 2014 (UTC)
@TomT0m: that would be hard to accomplish since each language edition of wikipedia might have different templates for the same topic (class). For now the suggested "template's main topic" might work well with Wikipedia templates, but later on we should aim for a "Wikidata template" property to link a class with the (recommended) Wikidata template for the class:
< Roads > Wikidata infobox search < Infobox:Roads >
. When Wikidata becomes its own client (see: Bugzilla55570) then it will make sense to maintain a central version of the infobox here so each language Wikipedia can adapt it to their own needs.--Micru (talk) 18:38, 7 July 2014 (UTC)
@Micru: I don't get your point. It does not seem different from article. We can have as many implementation of Infobox:Roads in any language version as we get different articles linked by the same item, even if they show different properties. This does not seem related to the use of a central infobox module to me. TomT0m (talk) 19:16, 7 July 2014 (UTC)
@TomT0m: There is more than just one infobox for each topic. Some wikipedias have generic infoboxes, other have more infoboxes for the same topic. This happens specially with municipality infoboxes, where some wikipedias prefer a generic infobox and other ones have an infobox per region. Anyhow, you can suggest the inverse of this one and we could create both, it cannot hurt.--Micru (talk) 19:42, 7 July 2014 (UTC)
It's not really a problem, basically a generic infobox at the higher level can be linked both way to the entity class. Both ways works. We can make the assumption that a generic infobox will be linked to a higher level class in the class tree, and more specific will be linked to classes more at the leafs of the tree. If we want to get a suitable infobox we go up the subclass tree and find the most specific infobox with a template matching in the language. It's does not seem to me like a problem of this property or its inverse. Let's not find wrong explanations and justification to our properties ;) TomT0m (talk) 21:34, 7 July 2014 (UTC)
@TomT0m: Changed title and proposed below. Let's hope for many productive uses :)--Micru (talk) 08:31, 8 July 2014 (UTC)

topic's main infobox[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: primary infobox or template of this subject

Motivation. See above.--Micru (talk) 08:31, 8 July 2014 (UTC)

  • Symbol support vote.svg Support. Reverse of property proposed just above this one. --- Jura 16:08, 9 July 2014 (UTC)


Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: language independent or context-specific label

Motivation. Sometimes it is needed to use a label as a qualifier of another property, or there is a label that only was valid during a certain period (to be used with qualifier "start/end date"). I also think that it could be used to model systems since inputs and outputs usually require a way of name the signals.--Micru (talk) 17:12, 8 July 2014 (UTC)

contained in[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: a material entity located inside another one with no parts in common

Basic property.--Micru (talk) 13:55, 9 July 2014 (UTC)

  • Symbol oppose vote.svg Oppose. contained_in had been a property of the Basic Formal Ontology (BFO), but it's being removed from BFO 2 per the draft specification in favor of a more generalized located in (P276) property. I think that's a move in the right direction; we can use located in to capture the meaning of contained in. Emw (talk) 03:56, 10 July 2014 (UTC)
  • @Emw: are you sure of that? Looking at "3.6.4 Location" it seems that it has been replaced by occupies_spatial_region which is similar to "contained in". The problem of "located in", also identified in BFO2, is that it needs some prepositional modifier to indicate the location relation between both entities. Instead of "contained in", we could think of a qualifier of "located in", maybe "spatial relation" with values "on", "inside", "above", etc.? --Micru (talk) 07:18, 10 July 2014 (UTC)

has role[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: something the subject does because of some special natural, social, or institutional set of circumstances

Needed to express which function a given part has in a system (it might be different depending on the system). Notifying @Emw:--Micru (talk) 14:32, 9 July 2014 (UTC)

Simply put, roles are things that are optionally manifested in other things. Roles are realized in things by virtue of some special natural, social, or institutional set of circumstances. Roles depend on those things for their existence. For example, roles include any of our various occupations, or the steering (Q499159) of a rudder (Q209760) from Micru's example. One would say that "E. coli has role pathogen", for example, because such bacteria do not have that role when outside an animal's gut. In contrast, one would not say "heart has role circulation", because hearts are typically found in bodies pumping one. (However one might say "heart has role dinner" when being eaten by a lion.) Another example is something like "hydrogen has role nutrient", as stated in the BFO ontology ChEBI, the reference ontology for chemicals of biological interest.
This brings me to how I would change the 'Description' value of this proposed property. It currently reads "the function an element fulfills in a given system". "Function", "element" and "system" all have significant meaning and would cause alignment problems with BFO ontologies as proposed.
"Function" in BFO is closely related to "role", but not the same. Functions manifest in something by virtue of its physical structure. "Function" differs from "role" in that the former always or almost always manifests in something by virtue of its physical structure, while the latter optionally manifests in something. For example, the means "heart has function circulation" would be preferred over "heart has role function", because hearts almost always circulate blood, and do so by virtue of their physical structure. Same with "hammer has function impact nails".
"Element" has strong associations with the set theory operator element of (ϵ). The distinction between an "element" and a "set" is what differentiates the basic membership properties instance of (P31) and subclass of (P279) -- these are often analogized to "element of" and "subset of". I would not want the proposed wording to imply that has role is only applicable for instances and not for classes. BFO permits usage of has role on both instances and classes and the proposed property should do the same.
Finally, "system" is a vague term and seems likely to produce undue confusion. Certainly Coco Chanel (Q45661) has a specific kind of role, the occupation fashion designer (Q3501317), and Escherichia coli (Q25419) has role pathogen (Q170065), but to say that either subject is "in a given system" is rather obtuse. Things that have a role can be part of a system, but that should not be necessary and so shouldn't be in the description. I think we can safely drop the word "system" from the description.
I would word the description as "something the subject does because of some special natural, social, or institutional set of circumstances", per BFO.
Micru, thanks for proposing this property. I think it's likely to become a significant positive outcome of the Wikidata:Requests_for_comment/Refining_"part_of" RFC. Emw (talk) 03:49, 10 July 2014 (UTC)
Description changed as per Emw's comment.--Micru (talk) 07:22, 10 July 2014 (UTC)
That sounds useful. But as the role/function distinction suggests, that may be tricky to work out. Something about which I was wondering: it would be interesting to have a property that would say the areas of intervention of a particular administrative unit (eduction, security, etc.) Would that be possible to say that with this property or would it pave the way to irredeemable messiness ? @Innocent bystander: --Zolo (talk) 09:04, 10 July 2014 (UTC)
@Zolo: "Has role" is for entities that change their function depending on the context. I do not think that an organization adopts different roles, it is created with a fixed set of "functions" in mind and it always fulfills those, for that reason I would recommend using use (P366) or proposing a new "organization function" property if p366 seems too bound to artificial objects.--Micru (talk) 07:30, 11 July 2014 (UTC)
  • Perhaps this should have a different label, so that users don't accidentally select it when they mean to add character role (P453). --Yair rand (talk) 16:31, 10 July 2014 (UTC)
  • @Yair rand: I have been thinking about this, and I reached the conclusion that the confusion would be normal because... they are the same property. Well, character role (P453) is constrained to "interpretative roles", but there is the question if we can generalize character role (P453) for all uses, or if we can exclude "interpretative roles" from this generic one. Would a "Constraint:Item|NOT property=cast member (P161)" work?.--Micru (talk) 07:30, 11 July 2014 (UTC)

number of parts[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: the number of parts that this object has in total or of a specific type (when qualifying "has part")

Different meaning than number of instances (P1114).--Micru (talk) 14:40, 9 July 2014 (UTC)

  • Pictogram voting comment.svg Comment: two-wheeler (Q233040) currently uses has part (P527) with wheel (Q446): number of instances (P1114) = 2 --- Jura 17:26, 9 July 2014 (UTC)
  • Symbol oppose vote.svg Oppose. I support the spirit of this property -- capturing cardinality constraints -- but I think we should use a generic cardinality property and merge number of instances (P1114) and this proposed property into it. (As a practical matter I would redefine P1114 to have the semantics of that generic property.) That's much closer to how OWL and existing major ontologies handle cardinality constraints. "Cardinality" might be too stuffy as a label for such a property -- perhaps we could get by with 'number' or 'has number', and supply a description that indicates it doesn't take phone numbers? Emw (talk) 04:02, 10 July 2014 (UTC)


Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: the shape an entity normally has

Basic property needed to generate descriptions.--Micru (talk) 14:57, 9 July 2014 (UTC)

  • Symbol support vote.svg Support --- Jura 16:08, 9 July 2014 (UTC)
  • Symbol support vote.svg Support, great idea! (It's surprising we don't have this already.) Emw (talk) 04:05, 10 July 2014 (UTC)
  • Symbol support vote.svg Support--Zolo (talk) 08:59, 10 July 2014 (UTC)
  • Human eyes aren't exactly spherical. How this property is supposed to be used seems unclear. --Yair rand (talk) 16:33, 10 July 2014 (UTC)

has agent[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: entity that performs this action

With aliases: "performed by", "done by", "executed by".--Micru (talk) 14:14, 11 July 2014 (UTC)