Wikidata:Property proposal/Archive/41
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
This archive page is full. Use Archive/42 or subsequent ones.
Please restrict each archive page to 80 proposals, to avoid the Lua error: too many expensive function calls issue that messes up previous archive pages.
Wikidata property sample
Description | if the sample entity is a property, not an item |
---|---|
Data type | Property |
Domain | properties with datatype property |
Example | related property (P1659) → father (P22) mother (P25) |
- Support Wikidata property example (P1855) only works with items. --- Jura 12:47, 10 October 2015 (UTC)
- Support - Mbch331 (talk) 12:50, 10 October 2015 (UTC)
Metadata properties
Read this first
If Semantic Web concepts like "range", "domain", "type", "Class", "subClassOf", "Property" and "subPropertyOf" are Chinese to you, I highly recommend reading:
The OWL 2 Primer explains those basic Semantic Web concepts. Once you've read that, use http://www.w3.org/TR/rdf-schema/#ch_properties as a reference for the definitions of "range", "domain", etc.
- rdf:type and rdfs:subClassOf are probably not very relevant for statements on properties.
- Range, domain and subproperty of are exceedingly relevant.
There are several more pieces of vocabulary relevant for statements on properties -- e.g. inverse of (owl:inverseOf) -- but I recommend understanding the basic properties first. Familiarity with them is essential for anyone discussing statements on properties. Emw (talk) 13:11, 14 November 2014 (UTC)
Status of metadata support
Statements on properties are now live.
- Comment not a property proposal => archived --- Jura 11:55, 18 November 2015 (UTC)
Properties for property domains
Properties used for:
- Specifying which items may bear a given property ("property domain")
- Specifying which values a given property may be assigned ("property value domain")
Originally proposed
These properties are currently in Wikidata:Property_proposal/Pending/4#Metadata properties, originating from Wikidata:Project_chat/Archive/2013/10#Property_Metadata:
- Range used for constraint ==> see Value Item Domain and Numerical value domain below
domain
Description | any resource that has this property is an instance of one or more of those classes. Implements rdfs:domain. Replaces (with slightly different semantics) {{Property documentation}} and {{Constraint:Type}} . |
---|---|
Data type | Item |
Template parameter | N/A |
Domain | Wikidata property (Q18616576) - Wikidata:Glossary#Property |
Allowed values | item(s) (or query??) By default, each value assumes relation instance of (P31) to the specified item type or to a subclass of (P279) of it. For other relations, to that class or to a subclass thereof, should be qualified with the sought property, like subclass of (P279). |
Example | father (P22) ==> person (Q215627) |
Source | Initially from domain of {{Property documentation}} on the talk page of each property |
Robot and gadget jobs | Initial creation to be performed by bots using {{Constraint:Type}} . |
Proposed by | Wikidata:Project_chat/Archive/2013/10#Domain |
- Discussion
Originally requested by User:Filceolaire at Wikidata:Project_chat/Archive/2013/10#Domain: "links to a class-item (an item which subclass of and instance of properties link to)." -- LaddΩ chat ;) 03:45, 12 November 2014 (UTC)
- Original discussion (Oct 2013)
- datatype item
- links to a class-item (an item which subclass of and instance of properties link to). The property should (mostly) only be used on items which are an instance of (P31) of items which are subclasses of the class-item specified by this property.
- matches the rdfs:domain property Filceolaire (talk) 18:06, 8 October 2013 (UTC)
- Conditional support. I would support storing domain claims only if the semantics matched those of rdfs:domain. This implies constraints that can be leveraged by semantic reasoners to do type inference, as summarized in http://www.ksl.stanford.edu/software/jtp/doc/owl-reasoning.html. These are "strong" constraints. User:Silver_hr made some informative comments on this in W3C standards for property "domain" and "allowed values". Emw (talk) 15:56, 14 October 2013 (UTC)
- @Emw : I doubt we can seriously align the semantics to those of owl like that, as we would have to ckeck the consistency of the whole wiki and of the database all the time. I'm pretty sure considering the size and perimeter of the database it would be kind of really hard, and that it would be all the time inconsistent, so anything could be logically deduced ... We need something weaker, and try to achive all ontology consistency and zero constraint violation with the tools we have. TomT0m (talk) 18:05, 14 October 2013 (UTC)
- Having the definition of 'domain' match rdfs:domain is independent of how we ensure consistency in the knowledgebase. It simply means that for a property P that has the domain C, "resources denoted by the subjects of triples whose predicate is P are instances of the class C." Whether we want to prevent inconsistent statements though measures in the UI or simply detect inconsistent statements after the fact as we currently do is an independent matter -- we can still use rdfs:domain as the formal definition of 'domain'. Emw (talk) 19:36, 14 October 2013 (UTC)
- Formal definitions in owl is useful if we want to prove that the onlogy is consistent and the datas are consistent. If there is inconsistencies, then by en:explosion principle then anything becomes virtually inferable, that makes inferences pretty useless, so we lose the advantages of having strong and well defined semantics. If a kitten can become a mayor, then we can't decently say the range of the mayor property is a subclass of human in those conditions. Or we need to make a special case in the ontology just for that, or to weaken the constraint insanely. That means if we do a owl export of that, the database will have to be badly curated before we actually can use it in a reasoner. TomT0m (talk) 20:23, 14 October 2013 (UTC)
- Using rdfs:domain as the definition of domain does not in itself prove that the ontology is consistent. It simply provides one of multiple criteria to show that. Consistency enforcement is a distinct, independent matter, as explained above.
- Furthermore, citing exceedingly rare counterexamples as a reason to abandon the idea of property domain and range constraints is in my opinion a red herring. First, we should ask ourselves if such counterexamples are actually valid. Can a kitten be a mayor, or can a horse be a senator? No, they can't -- by default, considering such things to be invalid subjects of properties conventionally restricted to humans is entirely reasonable. It is completely sensible to assert that kittens cannot be mayors. Second, if there is a compelling reason to expand the domain or range of properties beyond their conventional values, then we have a viable option in the case of crazy office holders or other subjects of properties conventionally restricted to humans: expand the domain from human (Q5) to person (Q215627). As described in the Wikipedia article Person, that term is quite the catch-all. Third, the fact that some properties might have unintuitively broad domains and ranges does not negate the fact that other properties actually do have well-defined domains and ranges. The domain of encodes (P688) is subclasses of gene (Q7187), and its range is subclasses of protein (Q8054) or RNA (Q11053). The statement BRCA1 (Q14862218) encodes (P688) kitten (Q147) is always wrong. Emw (talk) 22:05, 14 October 2013 (UTC)
- Formal definitions in owl is useful if we want to prove that the onlogy is consistent and the datas are consistent. If there is inconsistencies, then by en:explosion principle then anything becomes virtually inferable, that makes inferences pretty useless, so we lose the advantages of having strong and well defined semantics. If a kitten can become a mayor, then we can't decently say the range of the mayor property is a subclass of human in those conditions. Or we need to make a special case in the ontology just for that, or to weaken the constraint insanely. That means if we do a owl export of that, the database will have to be badly curated before we actually can use it in a reasoner. TomT0m (talk) 20:23, 14 October 2013 (UTC)
- Having the definition of 'domain' match rdfs:domain is independent of how we ensure consistency in the knowledgebase. It simply means that for a property P that has the domain C, "resources denoted by the subjects of triples whose predicate is P are instances of the class C." Whether we want to prevent inconsistent statements though measures in the UI or simply detect inconsistent statements after the fact as we currently do is an independent matter -- we can still use rdfs:domain as the formal definition of 'domain'. Emw (talk) 19:36, 14 October 2013 (UTC)
- @Emw : I doubt we can seriously align the semantics to those of owl like that, as we would have to ckeck the consistency of the whole wiki and of the database all the time. I'm pretty sure considering the size and perimeter of the database it would be kind of really hard, and that it would be all the time inconsistent, so anything could be logically deduced ... We need something weaker, and try to achive all ontology consistency and zero constraint violation with the tools we have. TomT0m (talk) 18:05, 14 October 2013 (UTC)
- Conditional support. I would support storing domain claims only if the semantics matched those of rdfs:domain. This implies constraints that can be leveraged by semantic reasoners to do type inference, as summarized in http://www.ksl.stanford.edu/software/jtp/doc/owl-reasoning.html. These are "strong" constraints. User:Silver_hr made some informative comments on this in W3C standards for property "domain" and "allowed values". Emw (talk) 15:56, 14 October 2013 (UTC)
- More discussion
Necessary to replace field domain of {{Property documentation}}
-- LaddΩ chat ;) 03:45, 12 November 2014 (UTC)
- Support --Paperoastro (talk) 21:42, 15 November 2014 (UTC)
- Conditional support. As @Emw: mentions, encodes (P688) should have domain gene (Q7187) and range protein (Q8054). But there are hundreds of Wikipedia articles (and therefore Wikidata items) about both the gene (Q7187) and the protein (Q8054), for example BRCA2 DNA repair associated (Q421651). Therefore the property encodes (P688) points to the same item. This happens for many other items where the domain and range are conflated in common language (and in Wikipedia articles). I support Domain, but are we prepared make items on Wikidata separate, even when the domain and range are conflated in Wikipedia (or invent a new semantics of Domain for these cases)? Jefft0 (talk) 13:17, 29 November 2014 (UTC)
- Jefft0, we should not diverge from the standard semantics of domain, i.e. rdfs:domain. This property will be an important basis for inference, like instance of (P31) having the semantics of rdf:type and subclass of (P279) having the semantics of rdfs:subClassOf. More specifically, Wikidata's domain property should take the semantics as used in OWL 2 DL, the reference ontology language of the Semantic Web.
- Your concern about conflation among relata is warranted. The folks at WikiProject Molecular biology have fortunately already split Wikidata's items about genes from items about their products; see Wikidata_talk:WikiProject_Molecular_biology#Distinguishing_between_genes_and_proteins. But conflation affects other swaths of knowledge -- e.g. infectious diseases are often conflated with their pathogen, and other effects with their causes.
- Having a domain property will standard semantics will help reveal these logical issues. It will also make Wikidata more interoperable with the rest of the Semantic Web. Emw (talk) 03:06, 4 December 2014 (UTC)
- Comment. Filceolaire, Laddo, TomT0m, Paperoastro, Jefft0, I have changed the proposed property's description from "type(s) of items that may bear this property" to an extremely close paraphrasing of the definition of rdfs:domain: "any resource that has this property is an instance of one or more of those classes". The former definition was vague and could be interpreted as having non-W3C semantics. It's important to align our definitions with the W3C standards to ensure interoperability with the rest of the Semantic Web. Emw (talk) 05:04, 19 December 2014 (UTC)
- Question: there are two different cases: {{Constraint:Type|class=Q8054|relation=subclass}} and {{Constraint:Type|class=Q5|relation=instance}}. Will the property used for both cases? — Ivan A. Krestinin (talk) 05:23, 19 December 2014 (UTC)
- Ivan, could you please link to where {{Constraint:Type|class=Q8054|relation=subclass}} is used? I am inclined to answer "yes" to your question, but I want to verify that example. Thanks, Emw (talk) 05:38, 19 December 2014 (UTC)
- Support the second definition. Paperoastro (talk) 12:15, 21 December 2014 (UTC)
- Oppose Oppose Ontotext's experience with large LOD datasets shows that the semantics of rdfs:domain and rdfs:range are often useless and even dangerous, because they propagate wrongly applied properties into wrong types.
- The "infer" semantics of these properties is surprising to most people (anyone with an OO background), who expect a "constraint" semantics.
- That's the reason why schema.org has NOT adopted rdfs:domain and rdfs:range but weaker schema:domainIncludes and schema:rangeIncludes. Please read "The decision to allow multiple domains and ranges was purely pragmatic" on that page and reflect upon it! schema.org is a large ontology, supported by all search engines, and has a good class hierarchy and good props.
- Wikidata has good props (due to strong editorial process) but horrible class hierarchy. Don't exacerbate this problem by inferring types from property assertions! Let's first look at how can we fix the class hierarchy.
- "is an instance of one or more of those classes" doesn't work with rdfs:domain&range, because rdfs:domain=class1,class2 infers both classes as type of object. Eg on dbpedia mapping wiki, someone said that the domain of firstAscentYear is Peak,Volcano (meaning either peak or volcano). But now every ascended thing becomes BOTH a peak and a volcano :-(
- The DBpedia ObjectProperty extractor doesn't pay attention to declared domain/range of properties (so on DBpedia these are "wishful thinking" really). So if you apply domain/range reasoning, you'll mis-type all kinds of objects.
- @Emw: in conclusion, don't use rdfs:domain and rdfs:range, use the weaker schema:domainIncludes and schema:rangeIncludes. --Vladimir Alexiev (talk)
- Support Sorry but can we put the philosophical discussion for later ? Right now we need a way to look for set od properties useful to describe one item and we can't do that: specific projects handles lists of properties with all update problems. I want to be able to filter properties tables like this one using one or several domains criteria. So let's go with this property. Snipre (talk) 11:45, 23 December 2014 (UTC)
- Oppose if this property does not support constructions like class1 or class2. We have too many multitype properties like IMDb ID (P345) already. — Ivan A. Krestinin (talk) 19:37, 23 December 2014 (UTC)
- I still Support this proerty but I agree with Vladimir Alexiev that it should be based on the schema:DomainIncludes rather than rdfs:domian. Filceolaire (talk) 23:47, 28 December 2014 (UTC)
- I would support starting with a "weak" property meaning "only items that are instances of at least one of the classes indicated here can have this property". So really a straightforward replacement for
Template:Constraint:Type|relation=instance
(not sure for |relation = subclass).
As for rdfs domain, am not opposed to creating it as a second, separate property, but I am not convinced it is really enforceable in Wikidata.
I am inclined to think those properties would be mostly useful as maintenance tools (sanity checks, add missing p31..) than for inferrence. "property:father domain:person" might tell us that everything with a father is a person, but I do not quite see the point of knowing that given that anyhow any item with a father statement should also be marked as an instance of person through P31 and P279.--Zolo (talk) 22:22, 29 December 2014 (UTC)
- Comment, I closed this as "not done" as we have the set at Properties_for_constraints and a series of values in P31. --- Jura 11:49, 18 November 2015 (UTC)
range
Description | the values of this property are instances of one or more of those classes. Implements W3C rdfs:range. Replaces (and uses different semantics from) allowed values of {{Property documentation}} and {{Constraint:Value type}} . |
---|---|
Data type | item (or query?)-invalid datatype (not in Module:i18n/datatype) |
Template parameter | N/A |
Domain | Wikidata property (Q18616576) - Wikidata:Glossary#Property |
Allowed values | item(s) (or query??). By default, each value assumes relation instance of (P31) to the specified item type or to a subclass of (P279) of it. For other relations, to that class or to a subclass thereof, should be qualified with the sought property, like subclass of (P279). |
Example | father (P22) ==> human (Q5) qualified with sex or gender (P21)==>male (Q6581097) |
Source | Initially from allowed values of {{Property documentation}} on the talk page of each property |
Robot and gadget jobs | Initial creation to be performed by bots using {{Constraint:Value type}} and {{Constraint:One of}} . |
Proposed by | -- LaddΩ chat ;) 03:45, 12 November 2014 (UTC) |
- Discussion
Necessary to replace field allowed values of {{Property documentation}}
. -- LaddΩ chat ;) 03:45, 12 November 2014 (UTC)
- Support but I think One of would be a better label. Filceolaire (talk) 16:01, 15 November 2014 (UTC)
- Support --Paperoastro (talk) 21:43, 15 November 2014 (UTC)
- Name changed from Value Item Domain because this is defining the Range of Items this property can link to. Wording changed so this can only be used to link to a class from which corresponds to the items which are acceptable values for this Property, as rdf:range. Filceolaire (talk) 22:23, 17 November 2014 (UTC)
- I have changed this proposed property's label from 'Item Value Range' to 'range', for simplicity, parallelism with domain, and emphasis of grounding in standard Semantic Web vocabulary. Emw (talk) 03:13, 4 December 2014 (UTC)
- I have now also changed the property's description to align with that from the W3C's definition of rdfs:range. This is the definition the rest of the Semantic Web uses; we should do the same. LaddΩ, please let me know if you disagree. Emw (talk) 02:26, 19 December 2014 (UTC)
- @Emw: Fair with me, you guys know way better how to best describe these concepts. -- LaddΩ chat ;) 03:24, 19 December 2014 (UTC)
- I've tweaked the description again to use an extremely close paraphrasing of the definition of rdfs:range: "the values of this property are instances of one or more of those classes". This change is purely syntactic and intended to make for easier reading and interpretation, while retaining the semantics of rdfs:range. Emw (talk) 05:08, 19 December 2014 (UTC)
- @Emw: Fair with me, you guys know way better how to best describe these concepts. -- LaddΩ chat ;) 03:24, 19 December 2014 (UTC)
- I have now also changed the property's description to align with that from the W3C's definition of rdfs:range. This is the definition the rest of the Semantic Web uses; we should do the same. LaddΩ, please let me know if you disagree. Emw (talk) 02:26, 19 December 2014 (UTC)
- Conditional support. Similar to my opinion on domain, I would support storing range claims only if the semantics matched those of rdfs:range. This implies constraints that can be leveraged by semantic reasoners to do type inference, as summarized in http://www.ksl.stanford.edu/software/jtp/doc/owl-reasoning.html. Emw (talk) 03:13, 4 December 2014 (UTC)
- Oppose Wait until a unique system for constraint definition is defined. We should sure to create properties which can be used in the future constraint check system. Snipre (talk) 12:33, 6 December 2014 (UTC)
- Constraints declared in statements on properties will not be enforced in Wikibase. I think that's wise; hard constraints are not a good idea at this phase in Wikidata's development. Domain and range are fundamental properties used throughout the Semantic Web. Bots and other tools can be built as we make statements about domain and range. Let's not wait another 6 months, let's create this property soon. Emw (talk) 19:41, 7 December 2014 (UTC)
- We don't need to have these constraints used in the Wikibase system but I don't want to use template in the talk page and statements to define constraints: only one place should be used to describe the constraints and to feed the constraint checking bots. Snipre (talk) 15:05, 9 December 2014 (UTC)
- Snipre, I agree. Statements on properties involving metaproperties like range, domain, inverse of, etc. would be the sole place for such constraints. In time, they would replace the system of templates currently used in property talk pages. But we need to create these properties first. Emw (talk) 01:21, 10 December 2014 (UTC)
- We don't need to have these constraints used in the Wikibase system but I don't want to use template in the talk page and statements to define constraints: only one place should be used to describe the constraints and to feed the constraint checking bots. Snipre (talk) 15:05, 9 December 2014 (UTC)
- @Snipre: Could you provide link to the system discussion, definition, roadmap or something else? — Ivan A. Krestinin (talk) 20:25, 12 December 2014 (UTC)
- @Ivan A. Krestinin: Better ask for Lydia. The only thing I have is this comment from her.
- Emw No. If there is no use, no creation. We should wait until we see the final system in order to create the correct and most appropriate properties. I don't want to have to modify and to delete an bunch of statements which were bad used. Snipre (talk) 07:41, 13 December 2014 (UTC)
- Snipre, again, constraints declared in statements on properties will not be enforced in Wikibase, per the Wikidata development plan. The development plan comes from Lydia. The reason statements on properties exist is to replace the hackish Property Talk page templates with content on the Property page itself. Range is a fundamental property used throughout the Semantic Web in precisely the way it is being proposed here. This is "the correct and most appropriate" property for what is being proposed here. Bot implementers and third parties using RDF exports cannot being work with this property until it is created. Waiting "until we see the final system in order" is putting the horse before the cart. If you have some reason to object to using range as defined in W3C standards (which is what is being proposed here) then please outline that. Otherwise, we should move forward and create this property.
- Ivan, Innocent bystander, Tobias, Zolo, others, could you please weigh in here, preferably including a concrete 'Support' or 'Oppose' vote with any explanation? I do not want to let this proposal languish for months. Let's decide to create it or not. If not, let's come up with things we need from the Wikidata development team in order to use this most basic of properties. I for one think we should get on with it and create this property for the reasons described above. Emw (talk) 02:38, 19 December 2014 (UTC)
- As for me the property is useless without other properties described in #Originally proposed section below. Also current suggestion mixes different relations: {{Constraint:Value type|relation=instance}}, {{Constraint:Value type|relation=subclass}}, {{Constraint:One of}}. I think we need concertize the property meaning. — Ivan A. Krestinin (talk) 05:03, 19 December 2014 (UTC)
- Emw If you read my comment you will see that I never speak about constraints enforced in Wikibase. Before any creation we have to have a good idea about what we will have at the end. First from the comment of Lydia I pointed it seems that a group of students is working on the constraints. Do you know that thing ? For me this is not clear so first we have to clarify that thing. Then if we create this property statements is it planned with the current bot to migrate from the current system using the talk page templates to the new statements system ? I am not against this property I just want a clear technical solution with the implication of all persons using these constraints. I want to avoid a mixture of systems, I want to be able to delete the talk page templates when I create the corresponding statements about the constraints. I don't want to see statements about constraints AND talk page templates at the same time because the next time we will have to change a constraint we have to know where we have to change it. Is my position clear now ? Snipre (talk) 10:03, 19 December 2014 (UTC)
- I know about the student group, but I do not see any activity of this group, no planes, no declarations, no roadmaps. So I think about current system migration from templates on talk pages to properties. This migration requires a number of new properties. But I want to avoid properties duplication. So created properties must be usable for constraints checks too. Now we already have some duplication: allowed values of
{{Property documentation}}
is duplicate class parameter of{{Constraint:Value type}}
and values of{{Constraint:One of}}
. This duplication present because allowed values is not defined enough. Relation between it and property values can be instance, subclass, value list or another. Will new domain property be bad defined too? — Ivan A. Krestinin (talk) 22:19, 19 December 2014 (UTC)
- I know about the student group, but I do not see any activity of this group, no planes, no declarations, no roadmaps. So I think about current system migration from templates on talk pages to properties. This migration requires a number of new properties. But I want to avoid properties duplication. So created properties must be usable for constraints checks too. Now we already have some duplication: allowed values of
- Emw If you read my comment you will see that I never speak about constraints enforced in Wikibase. Before any creation we have to have a good idea about what we will have at the end. First from the comment of Lydia I pointed it seems that a group of students is working on the constraints. Do you know that thing ? For me this is not clear so first we have to clarify that thing. Then if we create this property statements is it planned with the current bot to migrate from the current system using the talk page templates to the new statements system ? I am not against this property I just want a clear technical solution with the implication of all persons using these constraints. I want to avoid a mixture of systems, I want to be able to delete the talk page templates when I create the corresponding statements about the constraints. I don't want to see statements about constraints AND talk page templates at the same time because the next time we will have to change a constraint we have to know where we have to change it. Is my position clear now ? Snipre (talk) 10:03, 19 December 2014 (UTC)
- As for me the property is useless without other properties described in #Originally proposed section below. Also current suggestion mixes different relations: {{Constraint:Value type|relation=instance}}, {{Constraint:Value type|relation=subclass}}, {{Constraint:One of}}. I think we need concertize the property meaning. — Ivan A. Krestinin (talk) 05:03, 19 December 2014 (UTC)
- Constraints declared in statements on properties will not be enforced in Wikibase. I think that's wise; hard constraints are not a good idea at this phase in Wikidata's development. Domain and range are fundamental properties used throughout the Semantic Web. Bots and other tools can be built as we make statements about domain and range. Let's not wait another 6 months, let's create this property soon. Emw (talk) 19:41, 7 December 2014 (UTC)
- Support I see no harm in creating this and seeing where it leads us. Can't be more concrete at the moment, as I have not read up, on statements on properties yet. --Tobias1984 (talk) 08:13, 19 December 2014 (UTC)
- Oppose Oppose See #domain above --Vladimir Alexiev (talk) 02:30, 23 December 2014 (UTC)
- Like for the "range" proposal above, support a property replacing
Template:Constraint:Value type|relation=instance}}
and not opposed to a second property rdfs:range.
I guess the mention of{{Constraint:One of}}
, as well as the French header are mistakes, as they mean something different ("value must be one of those values", not "value must be an instance of one of those values"). --Zolo (talk) 22:40, 29 December 2014 (UTC)
- Comment, I closed this as "not done" as we have the set at Properties_for_constraints --- Jura 11:49, 18 November 2015 (UTC)
numerical value range
Description | Range of numerical values allowed to be associated with that property: meant to replace field allowed values of {{Property documentation}} . |
---|---|
Data type | Numerical range? List of numbers? Set?-invalid datatype (not in Module:i18n/datatype) |
Template parameter | N/A |
Domain | Wikidata property (Q18616576) - Wikidata:Glossary#Property |
Allowed values | Set of numerical values (how? dedicated items?) |
Example | number of deaths (P1120) ==> integers, 0 or positive |
Source | Initially from allowed values of {{Property documentation}} on the talk page of each property |
Robot and gadget jobs | Initial creation to be performed by bots |
Proposed by | Wikidata:Project_chat/Archive/2013/10#Range |
- Discussion
Originally requested by User:Filceolaire at Wikidata:Project_chat/Archive/2013/10#Range. -- LaddΩ chat ;) 03:45, 12 November 2014 (UTC)
- Original discussion (Oct 2013)
- datatype item
- links to a class-item (an item which subclass of and instance of properties link to). The property should (mostly) only only link to items which are an instance of (P31) of items which are subclasses of the class-item specified by this property.
- matches the rdfs:range property Filceolaire (talk) 17:55, 8 October 2013 (UTC)
Conditional support. I would support storing range claims only if the semantics matched those of rdfs:range. See comments in Domain section above. Emw (talk) 15:56, 14 October 2013 (UTC)- Struck per Filceolaire's comments. The proposal above this one has been changed to discuss range.
- More discussion
Necessary to replace field allowed values of {{Property documentation}}
.
A range implies... a minimum value and a maximum value? A domain? A set of allowed values? An item representing a numerical domain? -- LaddΩ chat ;) 03:45, 12 November 2014 (UTC)
- User:Laddo, see rdfs:range and https://www.google.com/search?q=rdfs%3Arange. I recommend Googling "rdf rdfs owl (name of property)" if you're unsure of the meaning of these proposals. These properties of properties should all be based on properties in RDF, RDFS and OWL -- i.e. Semantic Web standards.
- We should deprecate "allowed values" as soon as possible. It's unclear whether it refers to rdfs:range or owl:oneOf. Editors routinely use "allowed values" both ways, making the property quite ambiguous. Emw (talk) 12:38, 14 November 2014 (UTC)
- I agree that "allowed values" is kind of a melting pot at the moment, and I'd gladly get rid of it, but it's hard to stop using it as long as the properties from this section cannot be implemented. -- LaddΩ chat ;) 00:30, 15 November 2014 (UTC)
- Emw, LaddΩ If I am reading the definition you linked to properly it is saying that rdf:range should always link to a Class which in wikidata terms means it should always link to an item which has a subclass of statement. This means that rdf:range is not equivalent to this property. This property is for defining the acceptable values for date or number items which is quite different from rdf:range. Can you confirm that is your interpretation of rdfs:range ? Filceolaire (talk) 22:18, 17 November 2014 (UTC)
- Filceolaire, you're right, thanks for the careful reading. I've struck my support. There are other way to encode this information in OWL, but range is not it. Emw (talk) 03:47, 19 December 2014 (UTC)
- Emw, LaddΩ If I am reading the definition you linked to properly it is saying that rdf:range should always link to a Class which in wikidata terms means it should always link to an item which has a subclass of statement. This means that rdf:range is not equivalent to this property. This property is for defining the acceptable values for date or number items which is quite different from rdf:range. Can you confirm that is your interpretation of rdfs:range ? Filceolaire (talk) 22:18, 17 November 2014 (UTC)
- I agree that "allowed values" is kind of a melting pot at the moment, and I'd gladly get rid of it, but it's hard to stop using it as long as the properties from this section cannot be implemented. -- LaddΩ chat ;) 00:30, 15 November 2014 (UTC)
- Name changed from 'Numeric value Domain. Wording of the description changed to make clear this property refers to the Range and not the Domain. The more I look at this the more it seems to me that Domain and Range should link both to Query entities. Queries will have functions like has statement:Instance of:human and more than:0. and has format:NNN??#. Anyone else see that? Filceolaire (talk) 22:44, 17 November 2014 (UTC)
- @Filceolaire: I used "numerical domain" because I thought it might specify not only the min and max, but also the nature of acceptable values: real number (Q12916) (floats), integer (Q12503), natural number (Q21199), rational number (Q1244890)... I'm pretty sure a query is not adequate for a numerical domain/range, but since I haven't yet read rdfs:range, let me give a more informed opinion in a couple more days. -- LaddΩ chat ;) 02:18, 20 November 2014 (UTC)
- LaddΩ, rdf:range links to a class of items so it will be of no use for properties with date, numeric or text datatype. It is only for Properties with Item datatype. My point was that the kinds of properties we need for defining the range of Date, numeric and text datatypes look more like queries and less like the properties we use with itemsFilceolaire (talk) 11:17, 20 November 2014 (UTC)
- @Filceolaire: I used "numerical domain" because I thought it might specify not only the min and max, but also the nature of acceptable values: real number (Q12916) (floats), integer (Q12503), natural number (Q21199), rational number (Q1244890)... I'm pretty sure a query is not adequate for a numerical domain/range, but since I haven't yet read rdfs:range, let me give a more informed opinion in a couple more days. -- LaddΩ chat ;) 02:18, 20 November 2014 (UTC)
- Oppose Wait until a unique system for constraint definition is defined. We should sure to create properties which can be used in the future constraint check system.
- Comment, I closed this as "not done" as we have the set at Properties_for_constraints --- Jura 11:49, 18 November 2015 (UTC)
Originally proposed
These properties are currently in Wikidata:Property_proposal/Pending/4#Metadata properties, originating from Wikidata:Project_chat/Archive/2013/10#Property_Metadata:
- Dedicated item for property ==> Done Wikidata item of this property (P1629)
- Property ID ==> ??
- URL format ==> Done formatter URL (P1630)
- Subproperty ==> Done subproperty of (P1647)
- Equivalent property ==> Done equivalent property (P1628)
- Example ==> Done Wikidata property example (P1855)
- Main item ==> Done Wikidata item of this property (P1629)
These two were later added at Wikidata:Property_proposal/Pending/4#Statements about properties:
- License terms
- Place of publication
definition
Description | Textual description providing a clear & simple, unambiguous and non-technical description of what the property represents. |
---|---|
Represents | definition (Q101072) |
Data type | multilingual text ?-invalid datatype (not in Module:i18n/datatype) |
Template parameter | N/A |
Domain | Wikidata property (Q18616576) - Wikidata:Glossary#Property |
Allowed values | Text definition in each language |
Example |
|
Source | Initially based on description of {{Property documentation}} on the talk page of each property, without the technical portion |
Proposed by | -- LaddΩ chat ;) 00:10, 28 November 2014 (UTC) |
- Discussion
Support As the proposer, mainly because of statements like this excerpt from w:Wikipedia talk:WikiProject Ships#Fall back on Wikidata for Ship class:
<rant>
This last point is one of my pet peeves about Wikidata. The reason that we use named parameters in our templates is so that humans can understand the purpose of the parameter. We have|Ship name=
and|Ship commissioned=
and|Ship length=
and|Ship class=
and a whole raft of other parameter names that convey meaning to humans. Not so with Wikidata. Without we have some sort of dictionary, P289 is meaningless and that is a barrier to its use that must, must be changed.</rant>
(from User:Trappist the monk)
- We absolutely need a more lengthy and explicit description of a property, that can be accessed remotely for tooltip pop-ups, for example. This description is intended for non-technical users, and shall be distinct from Property usage further below, that aims at clarifying its technical usage for Wikidata contributors.
- -- LaddΩ chat ;) 00:10, 28 November 2014 (UTC)
comment: Editor Laddo has asked for my comments. I come here knowing nothing about Wikidata. That is my <rant />
. I am very much in favor of the liberal use of descriptions that aid understanding so for that reason I am in favor of Description. In re-reading my <rant />
, I think that I failed to get across the essence of what I wanted to say. If I am writing a template that uses some wikidata property, I can, I presume, troll wikidata until I find it and then I can include it in my template. Because I did the research, I know what that cryptic bit of text is and what it means (at least for the short term). Some time later another editor reading my template's code might be able to infer what {{#property:P289}}
is and does, but without she researches it, she won't know. So, perhaps what it is that I'm looking for is some way to alias {{#property:P289}}
to something that immediately conveys to a human reader what that property thing is / does without needing to look it up every time I see it (because I won't remember day to day what it means – I suspect that to be a common affliction, especially as we age).
Here is Editor Laddo's snippet of en:Template:Infobox ship characteristics/sandbox that uses {{#property:P289}}
:
{{#if:{{{Ship class|}}}<!-- either -->{{#property:P289}}|<tr style="vertical-align:top;"><td>Class & type:</td><td>
{{#if:{{{Ship class|}}}|{{{Ship class|}}}|[[{{#property:P289}}]]}}</td></tr>
}}
When I first saw this it was a meaningless change because I couldn't attach meaning to {{#property:P289}}
. After some study, I could infer that it might provide ship-class information if the template didn't already have it. If there were such a thing as {{#property_alias:ship_class}}
then Editor Laddo's code would look like this and anyone reading it would have a much better chance of understanding the code at first reading without needing a dictionary:
{{#if:{{{Ship class|}}}<!-- either -->{{#property_alias:ship_class}}|<tr style="vertical-align:top;"><td>Class & type:</td><td>
{{#if:{{{Ship class|}}}|{{{Ship class|}}}|[[{{#property_alias:ship_class}}]]}}</td></tr>
}}
I am old enough to remember programming in BASIC on the first IBM PCs. In those days, variable names were one or two characters. It was great to move on to C where variable names could mean something. Wikidata properties that are just numbers seem like a throwback to those not-so-great days of BASIC. Am I making any sense?
I would add one other, unrelated comment. At enwiki, the use of tooltips is rather strongly discouraged for reasons of accessibility (see en:Wikipedia:Manual_of_Style/Accessibility#Text).
—Trappist the monk (talk) 00:53, 29 November 2014 (UTC)
- Now using clearer
{{#property:ship class}}
in that infobox, since the "label" syntax is also supported (see mw:Wikibase/Notes/Inclusion syntax). -- LaddΩ chat ;) 02:39, 1 December 2014 (UTC)
- closing stale proposal as "not done". Description field is there. --- Jura 11:55, 18 November 2015 (UTC)
recommended qualifier
Description | Qualifier(s) that should be associated to statements using this property. |
---|---|
Data type | Property |
Template parameter | N/A |
Domain | Wikidata property (Q18616576) - Wikidata:Glossary#Property |
Allowed values | Any Wikidata property (Q18616576) allowed to be used as qualifier |
Example | position held (P39) recommended qualifiers electoral district (P768), replaces (P1365), end time (P582), replaced by (P1366), statement is subject of (P805) (see Property talk:P39) |
Source | Can be initially based on {{Constraint:Qualifier}} |
Proposed by | -- LaddΩ chat ;) 17:43, 13 November 2014 (UTC) |
- Discussion
Such a property would be the basis for constraining the use of qualifiers. -- LaddΩ chat ;) 17:43, 13 November 2014 (UTC)
- Support. Filceolaire (talk) 15:50, 15 November 2014 (UTC)
- Support --Paperoastro (talk) 21:31, 15 November 2014 (UTC)
- Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:30, 26 November 2014 (UTC)
- Oppose The qualifier is necessary or not. We have a data model so stay with an unique model with the minimal necessary information. Partial information are useless in a database. Snipre (talk) 19:14, 12 December 2014 (UTC)
- @Snipre: No they are not. This could mean this property is allowed here as a qualifier, so don't hesitate to use it. With a qualifier as a string descriptions, we could even give informations to the user on how it's supposed to be used in this context. TomT0m (talk) 20:27, 15 June 2015 (UTC)
- @Snipre: I'm afraid i disagree about partial information. To take the example above. Giving the current office held by a politician is useful information, just by itself. Every additional datum added is useful but adding info to one politician does not make all other politician bios useless. Wikidata will not ever be complete or finished but it will, eventually, be better than all the alternatives. Filceolaire (talk) 21:23, 18 June 2015 (UTC)
- There is already P1646 (P1646) I don't see how this one is different ? I would probably support a "suggested qualifier" property for qualifiers that *do not* need to be used in every statement though. --Zolo (talk) 09:07, 25 October 2015 (UTC)
- Comment, I closed this as "not done" as we have the set at Properties_for_constraints --- Jura 11:50, 18 November 2015 (UTC)
Description | ... |
---|---|
Data type | String |
Template parameter | see above |
Domain | Q5 |
Allowed values | \d+ |
Example | Robert Gibson (Q7344755) → {{FJC Bio|851}} |
Source | external reference, Wikipedia list article, etc. |
Robot and gadget jobs | import from enwiki |
- Motivation
(Add your motivation for this property here.) --- Jura 08:13, 8 October 2015 (UTC)
- Proposal format
- Oppose as proposed - appears malformed; lacks description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:40, 8 October 2015 (UTC)
- Oppose, has no description or rationale listed, and example is invalid. Josh Baumgartner (talk) 19:58, 27 October 2015 (UTC)
- Discussion
- Closed this as not done, because the request has been open for about a month and it lacks a proper motivation and description and the example is unclear. This makes it impossible to create the property. Mbch331 (talk) 11:40, 8 November 2015 (UTC)
- Mbch331: Rationale is "implement Wikidata phase 2". Additional details are available by clicking on the template link for full details. I took the liberty to structure the discussion above. --- Jura 12:26, 8 November 2015 (UTC)
- We shouldn't guess what it's meant for, we shouldn't go to other projects to see why a proposal has been done. The example doesn't match the allowed values, so the example is invalid. When asked for more information by 2 opposes, no information is provided. When I mark the proposal as not done, additional information is provided. The information needed to create a property should be provided upon the moment of proposing the property. And still not all information is provided. A link to a template isn't a property title. If you still want this property, place a proper request that doesn't make others guessing at what you want. Mbch331 (talk) 14:30, 8 November 2015 (UTC)
- It's not clear if all opposes actually read the proposal, so I'd rather not get involved. IMHO the template needs to be checked in detail to assess the proposal. Obviously, it can help to re-state the project goal each time and, yes, including "en:Template:" in the label isn't needed, but we wouldn't have done that anyways. --- Jura 15:50, 8 November 2015 (UTC)
- I assure you I read the proposal in full. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:54, 13 November 2015 (UTC)
- I assure the same. The description is "..." and the motivation is "(Add your motivation for this property here.)". I've gone further and read the linked template, but it is a WP template and doesn't say anything about Wikidata implementation. If we don't have that information, then there really isn't anything to work with here and thus my opposition until the proposal is fleshed out to actually explain what the property is, what it is meant to do, and how it should be implemented. Josh Baumgartner (talk) 00:43, 18 November 2015 (UTC)
- At least one of you had a look at the template. I wonder if there are several ways to implement this. Personally, I think there would be just one. Josh, could you list the variants? --- Jura 09:12, 18 November 2015 (UTC)
- It's not clear if all opposes actually read the proposal, so I'd rather not get involved. IMHO the template needs to be checked in detail to assess the proposal. Obviously, it can help to re-state the project goal each time and, yes, including "en:Template:" in the label isn't needed, but we wouldn't have done that anyways. --- Jura 15:50, 8 November 2015 (UTC)
- We shouldn't guess what it's meant for, we shouldn't go to other projects to see why a proposal has been done. The example doesn't match the allowed values, so the example is invalid. When asked for more information by 2 opposes, no information is provided. When I mark the proposal as not done, additional information is provided. The information needed to create a property should be provided upon the moment of proposing the property. And still not all information is provided. A link to a template isn't a property title. If you still want this property, place a proper request that doesn't make others guessing at what you want. Mbch331 (talk) 14:30, 8 November 2015 (UTC)
- Mbch331: Rationale is "implement Wikidata phase 2". Additional details are available by clicking on the template link for full details. I took the liberty to structure the discussion above. --- Jura 12:26, 8 November 2015 (UTC)
Dictionary of Art Historians
Description | entry in the Dictionary of Art Historians |
---|---|
Represents | Dictionary of Art Historians (Q17166797) |
Data type | String |
Domain | persons |
Example | Aby Warburg (Q60185) → warburga |
Source | external reference (for additions); mix'n'match list |
Formatter URL | https://dictionaryofarthistorians.org/$1.htm |
Robot and gadget jobs | yes |
- Motivation
- Support Wikidatans already undertook the task of matching this biographical database since June 2014. The entries have been matched by using described by source (P1343), but it's obvious that we would be better of is we linked to this database with a specific property. Jonathan Groß (talk) 12:24, 6 November 2015 (UTC)
- Discussion
- Support described at URL (P973) could work as well, but a dedicated property works better. --- Jura 13:03, 6 November 2015 (UTC)
- Support a separate property; makes this more easily findable. Spinster (talk) 17:13, 8 November 2015 (UTC)
- Support --Pasleim (talk) 09:25, 11 November 2015 (UTC)
@Jura1, Spinster, Pasleim: Done. Jonathan Groß (talk) 09:55, 23 November 2015 (UTC)
Norwegian organization number
Description | the organization's ID in the Norwegian Entity Registry |
---|---|
Represents | Norwegian organization number (Q11994066) |
Data type | String |
Template parameter | Used in no:Mal:Infoboks organisasjon |
Domain | Norwegian organizations |
Allowed values | [0-9]{9} |
Example | Wikimedia Norge (Q6985258) → 993101583 |
Source | The Entity Registry |
Formatter URL | http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=$1 |
Robot and gadget jobs | My bot can import values from nowiki and nnwiki. |
beam
Description | The beam of a ship is its width at the widest point as measured at the ship's nominal waterline. |
---|---|
Represents | beam (Q2376482) |
Data type | Number (not available yet) |
Template parameter | « maître-bau » dans fr:Modèle:Infobox Navire, "beam" in en:Template:Infobox ship career |
Domain | boats |
Allowed values | number with unit of distance |
Example | CMA CGM Bougainville (Q21008053) → 54 m |
Source | fr:Maître-bau en:Beam (nautical) |
- Motivation
Allow to describe the dimensions of boats on Wikidata. Tubezlob (🙋) 16:36, 6 October 2015 (UTC)
- Discussion
- Support Thryduulf (talk: local | en.wp | en.wikt) 01:05, 7 October 2015 (UTC)
- Support: this is a specific measurement. Josh Baumgartner (talk) 00:38, 20 October 2015 (UTC)
- Support. Joe Filceolaire (talk) 20:21, 25 October 2015 (UTC)
- @Thryduulf, Joshbaumgartner, Filceolaire: done. --Fralambert (talk) 14:29, 31 October 2015 (UTC)
draft
Description | The draft (American) or draught (British) of a ship's hull is the vertical distance between the waterline and the bottom of the hull (keel), with the thickness of the hull included; in the case of not being included the draft outline would be obtained. |
---|---|
Represents | draft (Q244777) |
Data type | Number (not available yet) |
Template parameter | « tirant d'eau » dans fr:Modèle:Infobox Navire, "draft" in en:Template:Infobox ship career |
Domain | boats |
Allowed values | number with unit of distance |
Example | CMA CGM Bougainville (Q21008053) → 16 m |
Source | fr:Tirant d'eau en:Draft (hull) |
- Motivation
Allow to describe the dimensions of boats on Wikidata. Tubezlob (🙋) 16:47, 6 October 2015 (UTC)
- Discussion
- Support Thryduulf (talk: local | en.wp | en.wikt) 01:05, 7 October 2015 (UTC)
- Support: Specific measurement. Josh Baumgartner (talk) 00:38, 20 October 2015 (UTC)
- Support. Joe Filceolaire (talk) 20:20, 25 October 2015 (UTC)
- @Thryduulf, Joshbaumgartner, Filceolaire: --Fralambert (talk) 14:41, 31 October 2015 (UTC)
- Motivation
All organizations in Norway have an organization number, so having it in Wikidata would be great. Jon Harald Søby (talk) 16:31, 12 November 2015 (UTC)
- Discussion
Strong support --Almondega (talk) 21:30, 14 November 2015 (UTC)
- Support Runner1928 (talk) 22:28, 16 November 2015 (UTC)
- Support Already used in infoboxes on nowp. Would definitely be good to have. Danmichaelo (talk) 21:09, 17 November 2015 (UTC)
- Support Thryduulf (talk: local | en.wp | en.wikt) 21:33, 17 November 2015 (UTC)
@Jon Harald Søby, Almondega, Runner1928, Danmichaelo, Thryduulf: Done. Jonathan Groß (talk) 11:05, 23 November 2015 (UTC)
Track gauge
Description | Q214519 (track gauge), use "track gauge" instead of "gauge" since other gauges exist, most notably Q904003 (loading gauge) |
---|---|
Data type | Number (not available yet) |
Template parameter | "track_gauge" or "gauge" as in:
|
Domain | rail network, rail line |
Allowed values | 0.01 ... 10 000 (steps: 0.01 mm) |
Example | Q660895 (Tōkaidō Shinkansen) => 1435. Allow qualifiers "from" and "to", since some lines have been re-gauged. |
Format and edit filter validation | ??? (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Source | ...
|
Robot and gadget jobs | Data could be collected from different Wikipedias |
Proposed by | Kwj2772 (talk) and HSRtrack (talk) |
- Support Joshbaumgartner (talk) 04:34, 9 May 2013 (UTC)
Opposethe name, and that the value includes a unit - I would restrict input to metric and mm. There are too many systems otherwise, Imperial, Portuguese, Spanish, Swedish, Prussian ... support the general idea. Please see the proposal for #Track gauge below. HSRtrack (talk) 18:24, 14 May 2013 (UTC) Changed to Support after merging the two proposals. HSRtrack (talk) 22:53, 23 May 2013 (UTC)- Comments: I agree with HSRtrack that is should be numeric (in mm, without unit). en:wiki uses this list: en:Template:RailGauge/entry_check.
- Small gauges <100 mm: Note that small gauges are used too (say under 100 mm), mostly for toys and models. In [:en:Template:RailGauge], they are not separated. Now about precision: if we adhere to the generic safe 3 significant figures of precision, we'll need decimal places when the gauge is under 100 mm.
- Definition in inches: Some rail gauges are defined in imperial measures originally (inches). These may well be converted to mm, provided that re-converting to inches results in the same defined imperial measure. This is called a round-trip conversion check. It can be demonstrated that in this an integer value in mm (say >100mm) corresponds to 1⁄32 inch or larger. (That is: calculating back from mm to inch results in 1⁄32 inches or larger, so there is no overprecision since there are no gauges defined by 1⁄64.)
- For gauges <100mm (including to-scale models) one should/could use decimal inch values. An issue here could be: when the scale is defined like 1:1⁄32, typically imperial, the round trip check should work. en:User:DePiep= -DePiep (talk) 10:07, 16 May 2013 (UTC)
- I added a section about units at en:track gauge. Support two decimal digits as found in en:List of rail transport modelling scale standards HSRtrack (talk) 16:50, 22 May 2013 (UTC)
- Support Don't worry about the number of decimals - datatype number can support any number of decimal places and nothing here will influence that. Filceolaire (talk) 12:58, 26 May 2013 (UTC)
- Maybe restriction to two decimal places is wanted, since it disallows inputs like 1000.0000000001, 1000.000000001 (one zero less), 1000.0000000002 HSRtrack (talk) 13:16, 26 May 2013 (UTC)
- IMHO it should be of "number with unit" datatype. --Ricordisamoa 18:34, 28 May 2013 (UTC)
- Why do we need unit? It will be simplier if use one unit. And in infobox we can make units conversion.--Ahonc (talk) 20:54, 28 May 2013 (UTC)
- If the unit is always "mm" as proposed, then it is redundant. If the unit can be different from mm, then it will render lot of data useless to many people. What is 1 Prussian foot? HSRtrack (talk) 21:40, 28 May 2013 (UTC)
- Why do we need unit? It will be simplier if use one unit. And in infobox we can make units conversion.--Ahonc (talk) 20:54, 28 May 2013 (UTC)
Track gauge (merged)
Some discussion below may be worth keeping.
Source diff: http://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Unsorted&diff=prev&oldid=42173146
Copied from Wikidata:Property_proposal/Unsorted#Track gauge | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Currently values are distributed between different Wikipedia, sometimes a value is in the Portuguese and not any other, sometimes in Spanish and not any other, sometimes in German and not any other... HSRtrack (talk) 02:30, 13 May 2013 (UTC)
This discussion seems to be duplicate of Wikidata:Property_proposal/Place#rail_gauge_.2F_.2F. Kwj2772 (talk) 17:23, 14 May 2013 (UTC) |
- Then please merge into the earlier one. -DePiep (talk) 09:38, 16 May 2013 (UTC)
- If Kwj2772 allows me to do so or better reverse merge since the "Track gauge"-proposal is much better developed. HSRtrack (talk) 17:18, 22 May 2013 (UTC)
- Just merge them. Kwj2772 (talk) 03:24, 23 May 2013 (UTC)
- If Kwj2772 allows me to do so or better reverse merge since the "Track gauge"-proposal is much better developed. HSRtrack (talk) 17:18, 22 May 2013 (UTC)
- There is already track gauge (P1064) for this and I feel like there is a reason to continue using this: It would allow to more precisly specify specify the gauges, for example for finland and russia, where one has 1524 and the other 1520, but both are claimed in discussions on dewiki to result in the same range due to differing tolerances. --Nenntmichruhigip (talk) 17:56, 10 September 2015 (UTC)
- Sorted from Wikidata:Property_proposal/Pending/2 for discussion.
- Oppose Use track gauge (P1064) instead. Josh Baumgartner (talk) 20:32, 18 November 2015 (UTC)
Not done - track gauge (P1064) already exists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 19 November 2015 (UTC)
Indigenous to
Description | area or ethnic group that a language, folk dance, cooking style or other cultural expression is found (or was originally found) |
---|---|
Data type | Item |
Template parameter | put Wikipedia infobox parameters here, if existing; ex: "population" in en:template:infobox settlement |
Domain | languages, dialects, folk dances, cooking styles, other cultural expressions |
Allowed values | administrative geographical areas, geographical features, ethnic groups. |
Example | dandiya raas (Q3629880) => Gujarat (Q1061) |
Source | external reference, Wikipedia article |
Robot and gadget jobs | Should or are bots or gadgets doing any task with this? probably not |
Proposed by | Filceolaire (talk) |
- Discussion
This property would be similar to endemic to (P183) but for languages, dialects, folk dances, cooking styles and other regional cultural expressions instead of species Filceolaire (talk) 00:25, 7 November 2014 (UTC)
- Support I was looking for a way to link instruments to where they're from but couldn't find any suitable property. This seems to be what I was looking for.
- One thing I would say, though, is that culture is the result of a group of people behaving in a common way and many (if not most) cultural things are really linked to an ethnic group (Q41710) or human social group (Q874405) (including religious groups) and then to specific areas via the regions those groups of people live in, rather than directly to an area. Not all groups of people have a clearly defined area either.
- Some examples: haka (Q3595586) is a dance of the Māori (Q6122670) of New Zealand (Q664), Muong (Q3236789) is spoken by the Muong people (Q72805) of Vietnam (Q881), t'rưng (Q7667735) is an instrument used by the Jarai people (Q2467559) and Bahnar people (Q1347290) of Vietnam (Q881), Miao (Q33813) is spoken by the Hmong people (Q219205) of southern People's Republic of China (Q148), Vietnam (Q881), Laos (Q819) and Thailand (Q869), Ainu cuisine (Q4697541) is the style of cooking of the Ainu people (Q101828) of northern Japan (Q17).
- How do you think things like that should be handled? - Nikki (talk) 02:25, 3 March 2015 (UTC)
- Nikki Description amended to add "ethnic group" as well as area. Filceolaire (talk) 21:22, 20 March 2015 (UTC)
- I don't think it makes sense to say that something is "indigenous to" an ethnic group. The adjective indigenous relates to places, not groups. It would make more sense to add ethnic group as a target for the property, i.e. "area that an ethnic group is found (or was originally found)". Kaldari (talk) 19:27, 13 November 2015 (UTC)
- Nikki Description amended to add "ethnic group" as well as area. Filceolaire (talk) 21:22, 20 March 2015 (UTC)
- Support Popcorndude (talk) 12:08, 15 September 2015 (UTC)
- Question Would this apply to foods as well? For example, could you say "tamales are indigenous to Mesoamerica"? Kaldari (talk) 23:13, 10 November 2015 (UTC)
- Yes Kaldari. This could be used for foods. Joe Filceolaire (talk) 09:52, 11 November 2015 (UTC)
playing range image
Description | image showing the playing range of the instrument |
---|---|
Represents | range (Q1042979) |
Data type | Commons media file |
Template parameter | "range" in en:Template:Infobox instrument, "Tonumfang" in de:Template:Infobox Musikinstrument and the equivalents in other languages. |
Domain | musical instrument (Q34379) |
Allowed values | Commons image files |
Example | double bass (Q80019) => commons:File:Range_contrabass.png, western concert flute (Q209554) => commons:File:Range_flute.png |
Source | infoboxes |
Robot and gadget jobs | Bots could import the values from infoboxes and check that the values are in commons:Category:Instrument_ranges or one of its subcategories |
- Motivation
image (P18) is normally used for an image of the instrument itself, which is completely different from the range of notes it can play. Nikki (talk) 12:01, 28 April 2015 (UTC)
- Discussion
Oppose.The images you link to show the upper note and the lower note that the instrument can play. Wouldn't it be much better to have statements giving the upper and lower notes? That way we could not only automatically generate these images we could also use this info in other ways? You could use this for the range a singers voice could achieve too. I would suggest using datatype "item" for these "upper note" and "lower note" properties - we can have items for each note all the way up to the highest and lowest notes large organs can achieve. Filceolaire (talk) 12:50, 28 April 2015 (UTC)- Support per Nikki's comment below. Filceolaire (talk) 19:34, 11 May 2015 (UTC)
- Why not both? I would support adding properties and items for the upper and lower notes too, but I don't think that would replace the images. Generating the images automatically is a nice idea in theory, but it's not that simple to do. Both examples I linked have more than simply two notes, plus you have to deal with things like choosing the best clef to use. Even if you figure out all the properties needed to provide enough information and create all the necessary items, you then need something which is capable of bringing it all together and something to generate the image itself. It's a rather complicated process to generate an image, especially when the images already exist. - Nikki (talk) 15:37, 29 April 2015 (UTC)
- Per Filceolaire, far better to have a property for the item representing the top note, and another for the bottom note. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:30, 30 April 2015 (UTC)
- As I said, I don't think two properties would replace the image, just like coordinate location (P625) and OpenStreetMap relation ID (P402) haven't replaced locator map image (P242) or route map (P15) and IPA transcription (P898) hasn't replaced pronunciation audio (P443), because they provide the data in different and largely incompatible formats. In this case, it doesn't provide an image but an image is what the existing infoboxes use and want to display.
- The existing images are stored on Commons and references to the images are duplicated across Wikipedias (e.g. commons:File:Range_flute.png is used by 25 different Wikipedias). It would make sense if the infoboxes could access references to the images from a central data repository instead of having to duplicate them. Isn't that exactly one of the reasons Wikidata exists?
- Not having this property will not stop the images from being added, they will just end up being added using image (P18) instead (as has already happened for western concert flute (Q209554)), which seems rather suboptimal, since as I mentioned, image (P18) would normally be used for pictures of the instrument itself, not for its playing range. They are images of two completely different things, so it makes sense to keep them separated.
- - Nikki (talk) 09:57, 10 May 2015 (UTC)
- OK. Lets have both. I have changed my vote above and added proposals for the "highest note" and "lowest note" below. Support. Filceolaire (talk) 21:55, 23 May 2015 (UTC)
- Support --- Jura 08:46, 22 May 2015 (UTC)
- Comment Odd that this hasn't been created yet. The additional proposals for properties by User:Filceolaire are at highest note (P1897) and lowest note (P1898), but unused for 7 weeks. Is there something wrong with this property proposal process? --- Jura 11:51, 4 July 2015 (UTC)
OpenBenchmarking entry
Description | Entry at the OpenBenchmarking.org database |
---|---|
Data type | String |
Domain | software, hardware |
Example | SuperTuxKart (Q971909) → http://openbenchmarking.org/test/pts/supertuxkart |
Source | external reference, Wikipedia list article, etc. |
Formatter URL | http://openbenchmarking.org/$1 |
- Motivation
OpenBenchmarking.org keeps a comprehensive database of hardware and software performance. That could be of use to Wikidata as it allows a third party to machine-readably get performance results from a Wikidata item. Pikolas (talk) 22:55, 30 June 2015 (UTC)
- Discussion
- "pts/supertuxkart" seems to be a test suite rather than a product result. That is why it is in "http://openbenchmarking.org/test/" rather than "http://openbenchmarking.org/results/". Results seem to be generally for particular PC configurations or for a range of products compared rather than for a particular product with a wikidata item and the 'OpenBenchmarking.org/results/' references are for that series of tests rather than relating to a particular product.
- or have I misunderstood? Joe Filceolaire (talk) 20:19, 22 July 2015 (UTC)
- Oppose unless Pikolas has more info. Joe Filceolaire (talk) 23:54, 20 August 2015 (UTC)
Not done - no support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 17 November 2015 (UTC)
option for grammatical category
Description | subject is one of the possible values for grammatical category object. |
---|---|
Data type | Item |
Domain | grammeme (Q2374489) |
Allowed values | grammatical category (Q980357) |
Example | subjunctive (Q473746) → grammatical mood (Q184932) |
Source | external linguistics reference |
Robot and gadget jobs | probably not |
- Motivation
I wish to expand our coverage of linguistics (Q8162). Popcorndude (talk) 00:18, 6 July 2015 (UTC)
- Discussion
or this could be called simply "grammatical category". Popcorndude (talk) 01:39, 6 July 2015 (UTC)
- A significant proportion of the uses of this can be found here. Popcorndude (talk) 16:53, 14 August 2015 (UTC)
- Popcorndude why not use "instance of" or "subclass of"? Joe Filceolaire (talk) 00:19, 21 August 2015 (UTC)
- Would it be acceptable to have subjunctive (Q473746) be subclass of grammatical mood (Q184932) and instance of grammeme (Q2374489)?
- It also seems to me that a particular grammatical category is not really a "class", but I'm open to discussion. Popcorndude (talk) 00:57, 21 August 2015 (UTC)
- @Popcorndude: There is linguistic discussions on the enwiki article on type–token distinction (Q175928). So yes, I say it's modellable by classes. There is a class of sentences in which a special grammatical category appears. If a sentence is made of words of other linguistic entities, then each linguistic entity can be bound to fulfil a grammatical role ... subjonctive is bound to a class of particular forms of verbs ...
- If I say that the "subjonctive" concept is very closely related to all the sentenses (or sentences parts) that are written in the subjonctive mode, would make sense ? We could say "this is subjonctive" irl. Then "subjonctive" would be a subclass of sentences, or the precise relevant linguistic items. "Grammatical mode" would be the metaclass (see Help:Classification) of all the relevant classes of sentences relevant to model grammar. I think this would do the trick.author TomT0m / talk page 07:19, 21 August 2015 (UTC)
- Sorry, I can't follow what is said here. I don't understand what this property is for too. :/ Could someone expand on this a bit? --SynConlanger (talk) 14:09, 21 August 2015 (UTC)
- User:SynConlanger, the idea was to link grammemes (past tense, subjunctive, perfect, dual, etc.) with the corresponding grammatical category (tense, mood, aspect, number, etc.). However, now that I think about it, User:TomT0m is right (so far as I understand him), and this could just as easily be modeled by having all the grammatical categories be subclasses of grammatical category, and then just have all the grammemes be subclasses of them and instances of grammeme. Is that what you meant TomT0m, or have I totally misunderstood your suggestion? Popcorndude (talk) 15:33, 21 August 2015 (UTC)
- @Popcorndude: I think we're on the same page :) I did not know the grammeme word. author TomT0m / talk page 15:40, 21 August 2015 (UTC)
- Grammeme is a quite obsolete term for an emic grammatical entity. It was in vogue during the "tagmemic linguistic" era. But I'm a phonetician/phonologist not a morphosyntactician so I may be wrong! But I got the point! I agree in having "grammatical category" < "tense" < "past" and the like (where < means "contains the subclass" or whatever it may be metadata-ly speaking). --SynConlanger (talk) 17:17, 21 August 2015 (UTC)
- In that case I will retract this proposal. I would not be surprised to find that some other term is now prefered to "grammeme", but it was an item that already existed, so it seems like I might as well use it anyway. Popcorndude (talk) 17:45, 21 August 2015 (UTC)
- Grammeme is a quite obsolete term for an emic grammatical entity. It was in vogue during the "tagmemic linguistic" era. But I'm a phonetician/phonologist not a morphosyntactician so I may be wrong! But I got the point! I agree in having "grammatical category" < "tense" < "past" and the like (where < means "contains the subclass" or whatever it may be metadata-ly speaking). --SynConlanger (talk) 17:17, 21 August 2015 (UTC)
- @Popcorndude: I think we're on the same page :) I did not know the grammeme word. author TomT0m / talk page 15:40, 21 August 2015 (UTC)
- User:SynConlanger, the idea was to link grammemes (past tense, subjunctive, perfect, dual, etc.) with the corresponding grammatical category (tense, mood, aspect, number, etc.). However, now that I think about it, User:TomT0m is right (so far as I understand him), and this could just as easily be modeled by having all the grammatical categories be subclasses of grammatical category, and then just have all the grammemes be subclasses of them and instances of grammeme. Is that what you meant TomT0m, or have I totally misunderstood your suggestion? Popcorndude (talk) 15:33, 21 August 2015 (UTC)
- Sorry, I can't follow what is said here. I don't understand what this property is for too. :/ Could someone expand on this a bit? --SynConlanger (talk) 14:09, 21 August 2015 (UTC)
object spatial depth
Description | 3rd dimension, other than length, width, etc., where this dimension is named "depth" |
---|---|
Data type | Quantity |
Domain | 3d objects, sample: cameras |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Robot and gadget jobs | import from https://www.freebase.com/digicams/camera_dimensions/depth |
- Support Needed for import from Freebase. Seems to be missing at Wikidata:Property_proposal/Pending/2#Length. --- Jura 10:35, 1 September 2015 (UTC)
- Isn't 'depth' just for holes? don't cameras have 'height'? Joe Filceolaire (talk) 02:44, 2 September 2015 (UTC)
- @Filceolaire: A camera is usually a three dimensional object :) Which means we need at least 3 numbers to describe the minimum bounding box (Q6865426) of it, usually called width, height and ... depth ? Anyway, to get rid of the wording, we should use a more precise definition, such as "horizontal, vertical and depth" or x,y,z coordinates of the bounding box of an object, where x is the front horizontal measure, y is the front vertical measure and z is the depth of the box, and the object is seen with the front to back side aligned with the z axis. It seems to be what we usually do :) author TomT0m / talk page 09:22, 2 September 2015 (UTC)
- Oppose. See Wikidata:Property_proposal/Pending/2. Spatial Length, Spatial Width and Spatial Hieght already approved and should be created any day no that we have the number with units datatype. I don't think we need both Width and Depth but maybe we should have Depth as an alias for Width. Joe Filceolaire (talk) 21:02, 12 September 2015 (UTC)
- Why do you think "depth" should be an alias for "width"? --- Jura 19:57, 14 September 2015 (UTC)
- Because if we have length, width and height we don't need a 4th spatial dimension. Actually it would probably be better to rename length as depth and make length an alias of width so we have width (alias length), height and depth. Joe Filceolaire (talk) 22:10, 14 September 2015 (UTC)
- But then you'd have things like Trans-Siberian railway (Q58767) as 9,289km deep. Thryduulf (talk: local | en.wp | en.wikt) 22:22, 14 September 2015 (UTC)
- It's worse than that. In English a football pitch has length and width. Do other languages have these four names (length, height, depth, width) with the same meanings. Plus (in English) a building has height above ground level but a hole has depth below ground level and so both refer to the vertical dimension in those cases Holes have a side-to-side width dimension and a front-to-back dimension which we can't call depth because that is the top-to-bottom dimension. Joe Filceolaire (talk) 22:44, 14 September 2015 (UTC)
- Plus you describe these as being the dimensions of the minimum bounding box (Q6865426) but those are different from the dimensions of the camera body (which doesn't include the sticky-out lenses) so it may need another property again. The more I think about this the more I confuse myself. Sorry Jura, Thryduulf. I guess I am not helping. Joe Filceolaire (talk) 22:44, 14 September 2015 (UTC)
- But then you'd have things like Trans-Siberian railway (Q58767) as 9,289km deep. Thryduulf (talk: local | en.wp | en.wikt) 22:22, 14 September 2015 (UTC)
- Because if we have length, width and height we don't need a 4th spatial dimension. Actually it would probably be better to rename length as depth and make length an alias of width so we have width (alias length), height and depth. Joe Filceolaire (talk) 22:10, 14 September 2015 (UTC)
- Why do you think "depth" should be an alias for "width"? --- Jura 19:57, 14 September 2015 (UTC)
- Comment There is no example. --AVRS (talk) 09:54, 15 September 2015 (UTC)
- Oppose use length (P2043), height (P2048), & width (P2049) and their sub-properties to spatially dimension objects. Exact choice of which to choose for which direction depends on the object being measured and what the norms are for that class of object. Josh Baumgartner (talk) 23:29, 6 November 2015 (UTC)
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:33, 20 November 2015 (UTC)
period
Template parameter | "epochs" in en:template:Infobox ancient site, likely others |
---|---|
Domain | archaeological and palaeontological sites and finds; historical events; geological sites |
Allowed values | historical eras, geological eras, cultural eras, regnal eras, etc. |
Source | external reference, Wikipedia list article, etc. |
- Motivation
This is a key piece of information for geology, archaeology, palaeontology and history items. Thryduulf (talk: local | en.wp | en.wikt) 12:43, 4 November 2015 (UTC)
- Discussion
Support, located in time zone (P421) is occasionally used to record this and I've wanted a way to correct it without getting rid of the data entirely. Popcorndude (talk) 13:22, 4 November 2015 (UTC)
- Support Technically the item should have dates, and the epoch should have dates, allowing them to be correlated by query, but that requires a much more complete database and such data is not always available. Linking an item to the epoch it is relative to makes common sense even if not strictly needed. (Note an earlier proposal which was rejected, though it was specific to writers.) Josh Baumgartner (talk) 23:48, 6 November 2015 (UTC)
- Dates may not even be knowable for all items, e.g. dates for archaeological sites may not be known without detailed excavation, if that has not been done then we cannot add the dates (and even if it has been done, many sources will not report anything more detailed than e.g. "Iron age"). And currently it is not easy in Wikidata to represent time periods given as, e.g. "late Roman", "mid-late 2nd century" or "pre 1700". Thryduulf (talk: local | en.wp | en.wikt) 18:36, 9 November 2015 (UTC)
- Support. This can also be used for works of fiction - these often get set in some period without ever getting specific about dates (sometimes they mix up stuff from hundreds of years apart cf Regency romance (Q7308029)). Joe Filceolaire (talk) 10:28, 11 November 2015 (UTC)
- I thought about fiction, but decided to propose a separate property for that - Wikidata:Property proposal/Creative work#set in period, which you were the first to support. My thinking was that geological/archaeological/palaeontological/historical sites are a very different set of items to creative works, but if you'd prefer only one property to cover both I wouldn't object (although I do prefer two). Thryduulf (talk: local | en.wp | en.wikt) 16:22, 11 November 2015 (UTC)
- Thinking about it you are probably right that these are different enough to justify having two properties. Joe Filceolaire (talk) 14:48, 12 November 2015 (UTC)
- I thought about fiction, but decided to propose a separate property for that - Wikidata:Property proposal/Creative work#set in period, which you were the first to support. My thinking was that geological/archaeological/palaeontological/historical sites are a very different set of items to creative works, but if you'd prefer only one property to cover both I wouldn't object (although I do prefer two). Thryduulf (talk: local | en.wp | en.wikt) 16:22, 11 November 2015 (UTC)
- Support very needed. Jheald (talk) 21:12, 17 November 2015 (UTC)
- Comment @Filceolaire, Jheald, Thryduulf, Joshbaumgartner: there was also the valid in period (P1264) property who might be extended/merged, although it was primarily intended to be used as a qualifier. author TomT0m / talk page 11:34, 25 November 2015 (UTC)
@Thryduulf, Popcorndude, Joshbaumgartner, Filceolaire, Jheald: Done time period (P2348) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:24, 24 November 2015 (UTC)
Statistical unit
Description | The statistical unit of the dataset (country, household, individual, etc) |
---|---|
Represents | statistical unit (Q3409269) |
Data type | Item |
Template parameter | « unité statistique » dans fr:Modèle:Infobox Jeu de données |
Domain | Jeu de données (dataset) |
Allowed values | Wikidata item (Q16222597), individual (Q795052), household (Q259059), country (Q6256) |
Example | Penn World Table (Q7163352) → country (Q6256) |
Format and edit filter validation | (exemple : 7 chiffres peuvent être validés avec le filtre d'édition Special:AbuseFilter/17) |
Source | référence externe, article de liste de Wikipédia, etc. |
Robot and gadget jobs | Devrait-il y avoir ou existe-t-il des bots ou des gadgets qui effectueront des tâches avec cette propriété? Par exemple: vérifier les autres propriétés afin d'être cohérent, collecter des données, automatiser un lien externe, etc. |
- Motivation
Je voudrais créer les propriétés sémantiques pour décrire un jeu de données. L'unité statistique permet de décrire l'élément représenté dans la base de données. Par exemple, ça peut être un pays dans le cadre des Penn World Tables, un individu dans la cadre d'un sondage, un ménage dans le cadre de l'Enquête Emploi, une voie ou une rue dans la cas du fichier FANTOIR de la DGFIP, un élément (Q16222597) pour Wikidata, etc.
I would like to create semantic properties which describe a dataset. A statistical unit is the unit of the dataset. For instance, this can be a country for the Penn World Tables dataset, an item for Wikidata, an individual in a poll, an household in an official statistical survey such as Labor Force survey or even a street in datasets like FANTOIR.
--PAC2 (talk) 15:34, 11 November 2015 (UTC)
Voir aussi Wikidata:Property_proposal/Unsorted#Variables. --PAC2 (talk) 08:44, 18 November 2015 (UTC)
- Discussion
- Support Popcorndude (talk) 16:21, 11 November 2015 (UTC)
- Support. Thryduulf (talk: local | en.wp | en.wikt) 21:40, 11 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 14:46, 12 November 2015 (UTC)
- Support Jheald (talk) 16:23, 15 November 2015 (UTC)
- Comment Should we also have a property to describe other columns of the dataset -- eg
- ⟨ dataset item ⟩ "contains column" Search ⟨ number of individuals (Q1613416) ⟩
series ordinal (P1545) [[Special:Search/Property:series ordinal (P1545)|Search]] ⟨ "2" ⟩
- to indicate, for example, that column 2 gives population sizes ? Jheald (talk) 16:23, 15 November 2015 (UTC)
- Of course, thats part of the plan. The "column" is only meaningful for tabular data. I think, we should have the property "contains variable" --PAC2 (talk) 10:51, 16 November 2015 (UTC)
- to indicate, for example, that column 2 gives population sizes ? Jheald (talk) 16:23, 15 November 2015 (UTC)
- Comment While "statistical unit" is certainly an accurate term for this (cf en:statistical unit), it's also rather a confusing term, since it is quite specialist terminology, and most people unfamiliar with the phrase might assume the property was for a unit in the sense of a metre or a second. Is there a case for using some other synonym for the property's label ? -- eg perhaps "explanatory variable" (though that's still not quite right). Jheald (talk) 13:11, 25 November 2015 (UTC)
- It 's difficult to find another term. "explanatory variable" is wrong. The "statistical unit" is the base item of the dataset. It could be books for a bibliographic database, a place of OpenStreetMap, an item for Wikidata, an household for the British Household Panel Survey. An "Observation" would also be appropriate (See Hadley's Wickham data semantics in this article http://www.jstatsoft.org/article/view/v059i10, page 3); --PAC2 (talk) 14:19, 25 November 2015 (UTC)
has list
Description | Wikimedia list related to this subject |
---|---|
Data type | Item |
Allowed values | instance of (P31): Wikimedia list article (Q13406463) |
Example | Spain (Q29) → list of cities of Spain (Q189098) (with qualifier of (P642) → municipality (Q15284)) |
- Motivation
In eswiki we want to link items of countries and municipalities to the list of municipalities for that country. I asked about it in the Project chat how to do it and they suggested the use of a generic property like "has list" that has to be created (because I found properties for specific lists but not a generic one to use for this use case). The idea is to put the list in the country element and get the list directly from the country element when needed and using arbitrary access from the municipality elements. Agabi10 (talk) 15:59, 15 November 2015 (UTC)
- Discussion
- Support I believe this would help querying the list items --Pajn (talk) 16:48, 15 November 2015 (UTC)
- Support. Thryduulf (talk: local | en.wp | en.wikt) 02:23, 16 November 2015 (UTC)
- Support Popcorndude (talk) 13:20, 17 November 2015 (UTC)
- Oppose Unless I'm mistaken, this is the inverse of is a list of (P360). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 24 November 2015 (UTC)
- @Pigsonthewing: Up to a point, but that shouldn't necessarily count against it. To start with, even when an inverse property like is a list of (P360) exists, there's no way to search and access that inverse relationship in Lua, eg from the infobox for Spain. Secondly, even given that P360 exists, how (even in SPARQL) does one find lists which are relevant to the whole of Spain ? The P360 statement might have the qualifier country (P17) = Spain (Q29) -- or it might not. It might be implicit in the thing that the list was of eg municipality of Spain (Q2074737) -- but it's quite hard to frame a search for "things which are specific to Spain" (that we might have a list of). Then one would need to check that the list was not subject to a further narrowing limitation -- eg "list of municipality of Spain (Q2074737) in Andulusia". And even with all that, one would still not get to the real motivation for this property, to identify lists related to Spain that are sufficiently significant to consider linking to from the infobox for Spain.
- I am not sure I see how all that could be achieved just with P360. Jheald (talk) 15:49, 24 November 2015 (UTC)
- @Pigsonthewing: If you have better ideas I accept suggestions. I asked in the Wikidata:Project chat and proposed this suggestion to stop people of eswiki from adding the list as instance of (P31) and removing the other elements for the municipalities. This is the best solution I get and it would be a lot of work for me to make our template to work with Lua instead of with Wikicode, so if you have a better solution I am completely willing to know it. -- Agabi10 (talk) 23:21, 24 November 2015 (UTC)
- Stöder -- Innocent bystander (talk) 10:28, 25 November 2015 (UTC)
- Support. I'm against creating inverse properties but in this case there is a solid need for this in an infobox which looks like it cannot be met any other way. Joe Filceolaire (talk) 11:05, 25 November 2015 (UTC)
intended public/target/designed for
Description | this work or product (or object) is intended to be read/watched by, or has been designed to that person or class of person, or animals, plants, … |
---|---|
Data type | Item |
Domain | classes of human (at least of beings :) subclasses of being (Q203872) human (Q5) , specific humans, animals, … |
Allowed values | works or artworks, object, class of object. |
Example | (could not fins an item for undergraduate person |
- Discussion
The subject item could be target market (Q198981) but I think it is broader than a commercial buisiness concept, but if anybody has a better idea ...
Motivation: seems a pretty common stuff to add, and useful to use a class of people as intended target. Maybe an alternative intended to use for <education> would be a good complement.
TomT0m (talk) 20:26, 1 April 2015 (UTC)
- Comment that would be audience (Q211198)? Have you something like e.g. young adult literature (Q1233720) in mind which has a tendency to overlap with genre (P136) or rather ratings like USK 16 (Q14920393) or with finer granularity subclasses of the population specified by interests like White Anglo-Saxon Protestant (Q256898) or male videogamers between 25 and 30, farmers from northern Kansas which I usually would not deem notable items in Wikidata? -- Gymel (talk) 18:41, 23 May 2015 (UTC)
- @Gymel: More like class of people as I said, and yes, if there is a need I'm ready to create such items. It's a good thing to be able to compress such complex statements with one item, maybe in the future a query. TomT0m (talk) 19:04, 23 May 2015 (UTC)
- How about a more general property like designed for or intended for? MSGJ (talk) 21:37, 10 June 2015 (UTC)
- @MSGJ: Agreed, I modified the proposal TomT0m (talk) 09:27, 12 July 2015 (UTC)
- Support. If this property gets approved then maybe someone smarter than me could get a bot to change all the <genre:young adult literature> statements to use this property instead. Filceolaire (talk) 14:42, 12 July 2015 (UTC)
- Oppose paid editors would welcome this as an opporunity to advertise their products. --Succu (talk) 20:56, 7 August 2015 (UTC)
- Comment The Library of Congress recently published an Thesaurus? of Demographic Group Terms, apparently with similar intention. They currently have only 400 terms but from the overall structure I'm getting the impression that this number eventually may go up to the hundreds of thousands - for any property applicable to humans you can define the corresponding "demographic" group of persons with that property. Do we have (or want) these kinds of items? -- Gymel (talk) 07:11, 10 August 2015 (UTC)
- Support I find Succu's objection without merit - we would have to delete official website (P856) and many others if that were a concern. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 17 November 2015 (UTC)
- Support Joe Filceolaire (talk) 17:51, 26 November 2015 (UTC)
online service
Description | the online service/online service provider tied to an item |
---|---|
Represents | internet service provider (Q11371) |
Data type | Item |
Template parameter | "onlineservice" in Infobox VG |
Domain | Numerous |
Example | Xbox 360 (Q48263) → Xbox network (Q170073) |
- Motivation
Per TomT0m's suggestion above ;) --George (Talk · Contribs · CentralAuth · Log) 19:17, 24 May 2015 (UTC)
- Discussion
- Support --AmaryllisGardener talk 21:13, 24 May 2015 (UTC)
- @Caliburn: please provide some more examples? MSGJ (talk) 21:42, 10 June 2015 (UTC)
- @MSGJ: Sure! PlayStation 3 (Q10683) => PlayStation Network (Q719629) · Individual games: ⟨ Call of Duty: World at War (Q207797) ⟩ online service (P2361) ⟨ Games for Windows – Live (Q2991004) ⟩--George (Talk · Contribs · CentralAuth · Log) 13:52, 16 June 2015 (UTC)
platform (P400) ⟨ Microsoft Windows (Q1406) ⟩
- @MSGJ: Sure! PlayStation 3 (Q10683) => PlayStation Network (Q719629) · Individual games:
- Support of course :) TomT0m (talk) 18:23, 16 July 2015 (UTC)
- Oppose --Succu (talk) 22:00, 6 August 2015 (UTC)
- @Succu: not really useful or even valid if you don't explain the vote. author TomT0m / talk page 09:26, 7 August 2015 (UTC)
- Once upon a time CompuServe (Q1122074) switched to serve internet services and failed soon. The description of this suggested property is hopelessly incomplete. --Succu (talk) 20:39, 7 August 2015 (UTC)
- @Succu: not really useful or even valid if you don't explain the vote. author TomT0m / talk page 09:26, 7 August 2015 (UTC)
- Support I find Succu's objection without merit - we have many other properties whose values may change with time. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 17 November 2015 (UTC)
- Support Joe Filceolaire (talk) 17:51, 26 November 2015 (UTC)
UN/LOCODE
Description | geographic coding scheme by UNECE |
---|---|
Represents | UN/LOCODE (Q499348) |
Data type | String |
Domain | city (Q515), transport infrastructure (Q376799) |
Example |
with classifier: 1 = port (for any kind of waterborne transport) 2 = rail terminal 3 = road terminal 4 = airport 5 = postal exchange office 6 = Inland Clearance Depot – ICD or "Dry Port", "Inland Clearance Terminal", etc. 7 = fixed transport functions (e.g. oil platform) B = Border crossing function0 = function not known, to be specified |
Source | http://www.unece.org/cefact/locode/service/location.html |
- Motivation
Use is highly advised by IMO for the automatic identification system (Q787197).--Kopiersperre (talk) 10:18, 13 November 2015 (UTC)
- Discussion
- Support. Separate property required for the UN/LOCODE classifier Joe Filceolaire (talk) 16:11, 14 November 2015 (UTC)
- Question how is that different from Property:P1937? --- Jura 16:19, 14 November 2015 (UTC)
- Oppose UN/LOCODE (P1937) is exactly this, but appears unused and needs some help with the formatter/filter and the like. Josh Baumgartner (talk) 00:18, 19 November 2015 (UTC)
Not done - UN/LOCODE (P1937) already exists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 19 November 2015 (UTC)
northwest coordinate of location map
Description | see above. use as qualifier. |
---|---|
Data type | Geographic coordinates |
Template parameter | Template:Location map (Q5625881) |
Domain | place |
Example | see above |
Robot and gadget jobs | Yes |
Proposed by | GZWDer (talk) |
- Discussion
GZWDer (talk) 13:16, 6 January 2015 (UTC)
- I would rather have a "northernmost latitude" and a "westernmost longitude" property with type = number (decimal value). Parsing it from a coordinate-type property seems needlessly complicated.--Zolo (talk) 08:04, 9 January 2015 (UTC)
- Thinking of it, maybe it is best to wait until there is Wikibase on Commons so that we can store the data directly there. --Zolo (talk) 09:00, 17 January 2015 (UTC)
- I think this is a bad decision. Get the value of the coordinates is simple enough, but the coordinates are stored in the designated type. —putnik 18:31, 27 April 2015 (UTC)
- We already have coordinates of northernmost point (P1332), coordinates of southernmost point (P1333), coordinates of easternmost point (P1334), and coordinates of westernmost point (P1335). Can't we use those instead (as Zolo asked)? They are not specific to a particular map projection. I'm inclined to oppose unless someone can tell me why we need something else. Filceolaire (talk) 20:02, 19 March 2015 (UTC)
- Map not need all four. What a couple of them should we choose? I think it might be a good solution to add these two parameters: "northwest coordinate" and "westernmost coordinate" (not only for location maps, but for future uses too). Weak support. —putnik 18:31, 27 April 2015 (UTC)
- No answer? then I guess I Oppose. Filceolaire (talk) 20:26, 10 April 2015 (UTC)
- I guess the idea is to create location maps with marks. If you have the coordinates of a city and a location map you still need to know which sector the location map is showing to put the mark for the city on the right place. --Pasleim (talk) 22:10, 20 May 2015 (UTC)
- Such qualifier is useful only for specific kind of map projection (Q186386) (usually small) in which latitude and longitude can be converted to x and y value in the picture of map using linear function (Q188597). However if you look at Antarctica.svg, the translation to x and y is rather complex. The general solution to the problem is creating function, which test whether the given coordinate is visible on the map, and converts it to pair of (x, y) in the picture. Paweł Ziemian (talk) 11:54, 13 June 2015 (UTC)
- @Filceolaire: A statement with coordinates of northernmost point (P1332) d:o 1333, 1334 and 1335 have all both latitude and longitude. Adding all four, therefor gives 4 longitudes + 4 latitudes = 8 numbers. That would give us an unsolvable system of linear equations (Q11203). We need exactly four numbers here to copy the functions of present templates like Template:Location map Andorra (Q12259). That is easiest accomplished by adding coordinates of the most NW and SE points of the map.
- @Paweł Ziemian: That also includes nations like Russia and Greenland. They are the exceptions, they cannot be solved in a simple way like most other nations and regions in the world. -- Innocent bystander (talk) 18:05, 6 July 2015 (UTC)
- Yes, I know. It was an example, where the problem is easiest to observe (I think). Paweł Ziemian (talk) 18:43, 6 July 2015 (UTC)
- Innocent bystander What if we take the 'northernmost' and 'southernmost' points and discard their longitude values and then take the 'easternmost' and 'westernmost' and discard the latitude. Now we have two latitude values and two longitude values and the problem of finding NW and SE coordinates from these is solvable. Greenland shouldn't be a problem nor should Russia since we specify which point is easternmost and which is westernmost. Antartica only has a 'northernmost' point, defining a circular map. Similarly for the Artic sea. Easy peasy.
- "Ah" you say "but that means the map of russia and of greenland is not square!" and I say that depends on which projection you are using. These maps are square if you use the Peters equal area projection for instance. This will, however, distort the shape of Russia and Greenland. You would be better to use a polar projection for the maps. The centre of this polar projection should be at a latitude half way between the 'northernmost' and 'southernmost' points and a longitude half way between the east and west extreme points. Not hard to calculate. The north south east and west limits of the maps should be at or beyond the NSEW extreme points. Sounds perfectly possible to me. Google earth does this all the time - draws a polar projection with a centre point wherever the centre of your screen is. I'm still Opposed to creating new properties. Filceolaire (talk) 00:27, 8 July 2015 (UTC)
- A map of Russia or Greenland with the same longitude in the left upper and left lower corner are possible to create, but they are aestheticly awkward. Maps with other kind of projections exists in these cases, so it is solvable. The problem is that somebody have to create these maps and templates. We are not flooded with such skilled users on Commons and the Wikipedias. -- Innocent bystander (talk) 05:05, 8 July 2015 (UTC)
- This guy got an individual engagement grant to do exactly these maps. You should talk to him. Filceolaire (talk) 22:33, 16 July 2015 (UTC)
- A map of Russia or Greenland with the same longitude in the left upper and left lower corner are possible to create, but they are aestheticly awkward. Maps with other kind of projections exists in these cases, so it is solvable. The problem is that somebody have to create these maps and templates. We are not flooded with such skilled users on Commons and the Wikipedias. -- Innocent bystander (talk) 05:05, 8 July 2015 (UTC)
- Such qualifier is useful only for specific kind of map projection (Q186386) (usually small) in which latitude and longitude can be converted to x and y value in the picture of map using linear function (Q188597). However if you look at Antarctica.svg, the translation to x and y is rather complex. The general solution to the problem is creating function, which test whether the given coordinate is visible on the map, and converts it to pair of (x, y) in the picture. Paweł Ziemian (talk) 11:54, 13 June 2015 (UTC)
- There are several use cases with map overlays, where the placement of the overlay object would be needed. I had thought of using the northernmost coordinate and it's companions, but they are coordinate points, consisting of both longitude and latitude. This means there has to be either a more suitable property (a corner point, such as presented here) or a more suitable datatype (lat or long only, and a corresponding property). I think the previous would be more lightweight. So, I Support --Susannaanas (talk) 08:37, 14 September 2015 (UTC)
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:21, 19 November 2015 (UTC)
southeast coordinate of location map
Description | see above. use as qualifier. |
---|---|
Data type | Geographic coordinates |
Template parameter | Template:Location map (Q5625881) |
Domain | place |
Example | see above |
Robot and gadget jobs | Yes |
Proposed by | GZWDer (talk) |
- Discussion
GZWDer (talk) 13:16, 6 January 2015 (UTC)
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:22, 19 November 2015 (UTC)
female ratio
Description | female part of the population/sample. Another way of entering data instead of using female population (P1539) and male population (P1540). Avoid using both. |
---|---|
Data type | Number (not available yet) |
Allowed values | >=0 and <=1 |
Example | Fryšták (Q1471150) → 0.514477 (in 2015); United States Senate (Q66096) → 0.20 (January 3, 2015) |
- Motivaton
- Support. --- Jura 12:11, 30 April 2015 (UTC)
- Discussion
- Oppose. We should not be creating special 'female' properties. Why isn't there a 'male ratio' property? Remember the row over separate categories for 'women poets' on en:WP. Lets not do that.
- I would delete female population (P1539) and male population (P1540) as well. Just use population (P1082) with qualifier applies to part (P518) then it can be used for all the cross tabs in the census - sex, age, religion, race, etc. Filceolaire (talk) 16:50, 30 April 2015 (UTC)
- @Filceolaire: Is it the concept you don't like or the formulation? How about a gender neutrally formulated property for the gender ratio? There is en:List of countries by sex ratio, but I'd rather see a percentage of total. Male ratio could work as well, but focus is frequently on the female part. --- Jura 17:04, 30 April 2015 (UTC)
- @Filceolaire: care to explain? --- Jura 02:19, 3 May 2015 (UTC)
- Jura, Antrocent I have been thinking about how we can express this in a gender neutral way. I think I would prefer the property was called "Proportion of population". Examples:
- "Proportion of population:0.8(applies to part:male)", "Proportion of population:0.2(applies to part:female)", "Proportion of population:0.1(applies to part:Roman Catholic)", "Proportion of population:0.08(applies to part:HIV positive)". When the number of people who identify as neither male nor female goes above 0.005 we should include them in the info boxes. With this property we can do that. We won't need to redefine the property. OK? Filceolaire (talk) 23:36, 5 May 2015 (UTC)
- This is tempting indeed and could store the information:
- Using a generic field mixing it with other information is always possible, but generally not preferred (the answer to the question asked by Filceolaire is here).
- In this case, it would complicate things twice:
- once we have to check if the property actually contains information about the gender ratio,
- then if it's the male or the female part.
- I suppose it's still not gender neutral, as one would have to pick one or the other when adding the statement. --- Jura 10:54, 8 May 2015 (UTC)
- This is tempting indeed and could store the information:
- Comment I changed the proposal to use 0.20 instead of 20%. This is more consistent with the datatype. It could still be displayed as a percentage. --- Jura 18:23, 30 April 2015 (UTC)
- Support gender ratio is a frequently referenced statistic. Antrocent (talk) 18:59, 30 April 2015 (UTC)
- Oppose: Sex ratio is a recognized statistic, but if we maintain it, is should be a single property ("sex ratio" or "gender ratio") with the method of computation detailed in the description. There should not be female and male properties. Personally, I think it would be even better to simply use population (P1082) with qualifiers to indicate actual population numbers of any identified genders and let the client calculate the ratio to meet their needs. However, I realize that in reality, the base numbers are not always available and only the derived value is made available for certain populations. Josh Baumgartner (talk) 16:57, 11 June 2015 (UTC)
- Josh, as I said above I think this should made more general so it can be used for other population tabs besides gender. Rename as "Proportion of population" with qualifier "Applies to part:Catholics/men/women/natives/born overseas etc. " Filceolaire (talk) 23:35, 18 June 2015 (UTC)
- @Filceolaire: I could get behind that. I think at this stage it is probably best to not do either of these two proposals, and instead have a fresh one for a more broad 'population proportion'. Josh Baumgartner (talk) 23:43, 18 June 2015 (UTC)
- Josh, as I said above I think this should made more general so it can be used for other population tabs besides gender. Rename as "Proportion of population" with qualifier "Applies to part:Catholics/men/women/natives/born overseas etc. " Filceolaire (talk) 23:35, 18 June 2015 (UTC)
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 19 November 2015 (UTC)
male ratio
Description | male part of the population/sample. Another way of entering data instead of using female population (P1539) and male population (P1540). Avoid using both. |
---|---|
Data type | Number (not available yet) |
Allowed values | >=0 and <=1 |
Example | Fryšták (Q1471150) → 0.485533 (in 2015); United States Senate (Q66096) → 0.80 (January 3, 2015) |
- Motivation
- Comment complement to "female ratio" above, given Filceolaire's comment above about proposing "female ratio" only being biased. @Filceolaire, Antrocent:. --- Jura 22:38, 31 May 2015 (UTC)
- Discussion
- Oppose. Both 'male ratio' and 'female ratio' ignore the existence of people whose sex is unknown or is something other than male or female. For some populations the 'unknown' or 'wouldn't say' group can be significant (neither male nor female is generally pretty rare). See my comments on 'female ratio' above. Filceolaire (talk) 00:12, 3 June 2015 (UTC)
- Support Sex ratio is a recognized statistical number.--Kopiersperre (talk) 15:17, 11 June 2015 (UTC)
- Oppose Sex ratio is a recognized statistical number, so there should be a single property ("sex ratio" or "gender ratio") with the method of computation detailed in the description. There should not be female and male properties. Personally, it would be even better to simply use population (P1082) with qualifiers to indicate actual population numbers of any identified genders and let the client calculate the ratio to meet their needs. However, I realize that in reality, the base numbers are not always available and only the derived value is made available for certain populations. Josh Baumgartner (talk) 16:40, 11 June 2015 (UTC)
- "I realize that in reality": So, what do you suggest for this? --- Jura 19:50, 11 June 2015 (UTC)
- @Jura1: exactly what I stated above: "there should be a single property ("sex ratio" or "gender ratio") with the method of computation detailed in the description. There should not be female and male properties." Josh Baumgartner (talk) 18:23, 12 June 2015 (UTC)
- So you would agree to "Gender ratio: 0.8" (Property description: method of computation: male population/total population)? --- Jura 23:03, 12 June 2015 (UTC)
- @Jura1: yes. Josh Baumgartner (talk) 16:55, 15 June 2015 (UTC)
- ok, done. --- Jura 07:14, 23 June 2015 (UTC)
- @Jura1: yes. Josh Baumgartner (talk) 16:55, 15 June 2015 (UTC)
- So you would agree to "Gender ratio: 0.8" (Property description: method of computation: male population/total population)? --- Jura 23:03, 12 June 2015 (UTC)
- @Jura1: exactly what I stated above: "there should be a single property ("sex ratio" or "gender ratio") with the method of computation detailed in the description. There should not be female and male properties." Josh Baumgartner (talk) 18:23, 12 June 2015 (UTC)
- "I realize that in reality": So, what do you suggest for this? --- Jura 19:50, 11 June 2015 (UTC)
- Sorted up next to the proposal for female ratio, as they are related proposals. Josh Baumgartner (talk) 16:55, 15 June 2015 (UTC)
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:17, 19 November 2015 (UTC)
gender ratio
Description | gender distribution of the population/sample. Method of computation: female population/total population |
---|---|
Data type | Number (not available yet) |
Allowed values | >=0 and <=1 |
Example | Fryšták (Q1471150) → 0.515477 (in 2015); United States Senate (Q66096) → 0.20 (January 3, 2015) |
- Note
reformulated proposal per suggestion above by Joshbaumgartner. @Kopiersperre, Antrocent: --- Jura 07:14, 23 June 2015 (UTC)
- Motivation
- Support --- Jura 07:14, 23 June 2015 (UTC)
- Discussion
- Oppose if this is only used for the female population. This should be a general property "proportion of population" which is used with qualifier applies to part (P518) to indicate if the proportion quoted refers to male or female or transgender or unknown gender or african american or finnish speaking or Catholics or high school graduates or any other tab in a population census. Filceolaire (talk) 16:42, 28 June 2015 (UTC)
- I think you already mentioned that above. --- Jura 12:40, 4 July 2015 (UTC)
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:19, 19 November 2015 (UTC)
Metadata properties
Please complete discussions on Wikidata:Property proposal/Property metadata before implementing these new properties.
per This request, property metadata should be stored as statements. So I reopen these request:
# | Property Name | datatype | |
---|---|---|---|
1 | Dedicated item for property | item | Wikidata item of this property (P1629) |
2 | Property ID | string | |
3 | URL format | string | formatter URL (P1630) |
4 | Constraint type | item | property constraint (P2302) |
5 | Property used for constraint | item | property (P2306) |
6 | Item used for constraint | item | item of property constraint (P2305) |
7 | Format used for constraint | item | is pollinated by (P1703) |
8 | Range used for constraint | time+number | maximum value (P2312), minimum value (P2313) |
9 | Subproperty | item | subproperty of (P1647) |
10 | Equivalent property | url | equivalent property (P1628) |
11 | Example | all | Wikidata property example (P1855) |
12 | Main item | item | Wikidata property (P1687) |
--GZWDer (talk) 14:03, 30 October 2013 (UTC)
- Just for your information: properties on properties can't currently be stored until we close bugzilla:49554. I currently can't give a date for that but it will not happen before the end of this year. --Lydia Pintscher (WMDE) (talk) 14:53, 23 November 2013 (UTC)
- What is the difference between Dedicated and main items? --Infovarius (talk) 12:45, 18 October 2014 (UTC)
Statements about properties
A while ago there was a discussion about statements about properties. Since then WMF legal have published meta:Wikilegal/Database Rights which includes the advice that:
For EU databases, bots or other automated ways of extracting data should also be avoided because of the Directive’s prohibition on “repeated and systematic extraction” of even insubstantial amounts of data.
This suggests another couple of statements we need to be able to make about our authority control properties and other properties that refer to databases.
- License terms
- Place of publication
Filceolaire (talk) 23:09, 22 November 2013 (UTC)
- Some time ago it was decided that the best place to store property metadata was on the property page itself with statements. License info also could go there (using copyright license (P275)). The thing is that property pages do not accept statements, that's why we haven't processed yet some other related properties (for instance these or this). Is there any difficulty in unlocking property pages for adding statements?--Micru (talk) 08:40, 23 November 2013 (UTC)
- According to Lydia, meta-properties depend on bugzilla:49554. I will copy this conversation to Wikidata:Property proposal/Pending/4 (properties depending on the bug) for future reference.--Micru (talk) 15:40, 23 November 2013 (UTC)
- Done all created during the last 12 months. --Pasleim (talk) 19:58, 27 November 2015 (UTC)
Spatial extent
Description | Spatial extent for the object along some axis, in positive direction perpendicular from a reference plane, what is most commonly referred to as its maximum width in some direction. |
---|---|
Represents | height (Q208826) |
Data type | Number (not available yet) |
Template parameter | for example "elevation" in w:en:template:infobox mountain above the geoid WGS84 (Note that "elevation" is interpreted as grade/slope in some languages.) |
Domain | Any object with spatial extent |
Allowed values | All positive one-dimensional values with a length unit |
Example | The height of a mountain Glittertind (Q397876) |
Robot and gadget jobs | Bots would collect this from both articles in Wikipedia and use external datasets |
Proposed by | Jeblad (talk) |
- Discussion
This is a spatial extent for an object in some direction, going perpendicular on a plane, and unless otherwise specified it is the maximum length in any direction.
- A qualifier instance of (height (Q208826) is this right?) would take whats given as subject item above and will specify what the extent measure. (For example the height of a mountain.)
- A qualifier geoid (perhaps better called datum) which gives the interpretation of the items referenced, that is a height is according to the instance of. Default is WGS84 (World Geodetic System (Q215848)).
- A qualifier reference item which would be interpreted according to the instance of and geoid if that is given. The measured length is by extension to the surface of this item. Could be an extended plane.
- A qualifier extent coordinate system to specify the local coordinate system. Default is spherical coordinate system (Q203218).
- A qualifier azimuth or orientation according to the instance of and geoide. Defaults to "unknown".
- A qualifier inclination or polar angle according to the instance of and geoide. Defaults to "unknown".
Tried to reformulate the spatial extents to be a single generic one. It seems that there is a problem whether the system is a local one when the reference system point back to itself or the geoid is undefined, or it is a global one references something else. One way around could be to drop geoid and only use reference item and infer geoid from this item. The item lives within some other system or is self referencing. No reference item would be interpreted as a self reference.
Note that if the azimuth and/or inclination is set wrong the measurement axis my never touch the surface of the reference item. Jeblad (talk) 01:38, 30 October 2014 (UTC)
- Wait until we have the 'number with dimension' datatype, though I am really not clear how this is used and whether it would be better using a collection of specific properties such as 'Base' for mountains. Filceolaire (talk) 20:59, 31 October 2014 (UTC)
- Filceolaire can you point me to wherever a discussion about a 'number with dimension' datatype is going on? Getting a quantity datatype right is difficult, but rather easy compared to a dimension datatype. To make an example, a length dimension can exist and within that dimension there can be two length measures that can not be compared. Most of the time this situation arise because of lost knowledge about how base units relates, or becase there is (or was) conflicting definitions. My favorite example is the length measure "coffestops", see also m:Wikidata/Notes/Values. Another nice one is that "there are 4 stone throws (w:no:Steinkast) on one arrow shot (w:no:Pilskudd)", that is old Norse length measures. There is also "vika sjóvar" which is the distance you row a boat in two hours, which is calculated to be 11 112 meter on Wikipedia. :D In effect you have subdimensions within a dimension, but note that subdimensions in this case does not imply subclasses you can cast to a common baseclass (length is an abstract property and you can't cast a coffestop to a base class). Anyhow, I think it is better to create usable solutions and reprocess existing properties later when someone create the perfect solution. Jeblad (talk) 15:32, 5 November 2014 (UTC)
- See Wikidata:Requests_for_comment/Dimensions_and_units_for_the_quantity_datatype. Filceolaire (talk) 19:08, 5 November 2014 (UTC)
- I saw that page, didn't realize it was a proposed as an implementation. As it stands it is probably not a solution, in fact I think it will make it really hard to solve some real-world problems.
- Perhaps I should try to make a better explanation. That page describe the preferred units to use, it does not describe the role the measurement have. A property (predicate) describes the role a specific value (object) has in relation to an item (subject). An extent is such a property, and that will use a length measurement, possibly with units according to the given page. It is possible to use a length as a property, but then you must add qualifiers to say that this is in fact an extent. I think it is better to say what you measure with the property itself, and then add refinements to that, otherwise you need qualifiers about qualifiers (statements about reified statements about reified statements). An extent can have an orientation, but a length does not have one. It might not even be a measurement in a straight line. Jeblad (talk) 19:43, 5 November 2014 (UTC)
- See Wikidata:Requests_for_comment/Dimensions_and_units_for_the_quantity_datatype. Filceolaire (talk) 19:08, 5 November 2014 (UTC)
- Filceolaire can you point me to wherever a discussion about a 'number with dimension' datatype is going on? Getting a quantity datatype right is difficult, but rather easy compared to a dimension datatype. To make an example, a length dimension can exist and within that dimension there can be two length measures that can not be compared. Most of the time this situation arise because of lost knowledge about how base units relates, or becase there is (or was) conflicting definitions. My favorite example is the length measure "coffestops", see also m:Wikidata/Notes/Values. Another nice one is that "there are 4 stone throws (w:no:Steinkast) on one arrow shot (w:no:Pilskudd)", that is old Norse length measures. There is also "vika sjóvar" which is the distance you row a boat in two hours, which is calculated to be 11 112 meter on Wikipedia. :D In effect you have subdimensions within a dimension, but note that subdimensions in this case does not imply subclasses you can cast to a common baseclass (length is an abstract property and you can't cast a coffestop to a base class). Anyhow, I think it is better to create usable solutions and reprocess existing properties later when someone create the perfect solution. Jeblad (talk) 15:32, 5 November 2014 (UTC)
- In this case instance-of seems to be right as this would be a statement about a height, that is a height measurement. Usually it is wrong to use instance-of as a qualifier, that is rdf:type about a statement. Jeblad (talk) 02:32, 23 November 2014 (UTC)
- Comment. Jeblad, Filceolaire, how about using first-class properties like height (or spatial height) when applicable, and this property for more complex spatial extents? This approach works well for our kinship properties, where we have first-class properties like mother, father, brother, sister and child for basic relations, and relative with a type of kinship qualifier for more distant relations. Emw (talk) 01:11, 9 December 2014 (UTC)
- Emw There are 75 properties using this data type listed on Wikidata:Property_proposal/Pending/2 which have been approved and are waiting, pending the creation of this datatype. Check there and see if the property you are proposing is already approved. Filceolaire (talk) 23:25, 17 December 2014 (UTC)
- I believe property extent gives a more general solution than length in Wikidata:Property_proposal/Pending/2, and it will also cover minor axis. Remember, generalize! Jeblad (talk) 14:02, 28 February 2015 (UTC)
- I wonder if there should be no default for geoid, and the interpretation should be length along major axis. The next minor axis in following order will then give the reference system according to the right hand rule. Jeblad (talk) 14:11, 28 February 2015 (UTC)
- I believe property extent gives a more general solution than length in Wikidata:Property_proposal/Pending/2, and it will also cover minor axis. Remember, generalize! Jeblad (talk) 14:02, 28 February 2015 (UTC)
- Emw There are 75 properties using this data type listed on Wikidata:Property_proposal/Pending/2 which have been approved and are waiting, pending the creation of this datatype. Check there and see if the property you are proposing is already approved. Filceolaire (talk) 23:25, 17 December 2014 (UTC)
On hold pending data type. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:56, 22 March 2015 (UTC)
Done elevation above sea level (P2044) and height (P2048) --Pasleim (talk) 20:03, 27 November 2015 (UTC)
Australian Stratigraphic Units Database STRATNO
Description | identifier for a stratigraphic unit listed in the Australian Stratigraphic Units Database |
---|---|
Represents | stratigraphic unit (Q3694119) |
Data type | String |
Template parameter | No infobox parameter is known to currently exist, however a new parameter could be included within the template en:template:infobox rockunit |
Domain | stratigraphic unit (Q3694119) where located in/on physical feature (P706) = Australian continent (Q3960) (approximation only) |
Allowed values | string pattern: \d+ |
Example | Gascoyne Complex (Q5526405) → 7044 |
Source | external reference, Wikipedia list article, etc. |
Formatter URL | http://dbforms.ga.gov.au/pls/www/geodx.strat_units.sch_full?wher=stratno=$1 |
Robot and gadget jobs | STRATNO IDs could be scraped from the Australian Stratigraphic Units Database and then imported into Wikidata using mix-and-match |
- Motivation
Properties Litholex ID (P731), BGS Lexicon of Named Rock Units ID (P732) and DINOloket ID (P733) are examples of similar properties which exist for stratigraphic unit identification systems of other countries. This property proposal allows for Australian stratigraphic units to be linked to the authoritative catalogue (the Australian Stratigraphic Units Database) for such information on Australia.
The Australian Stratigraphic Units Database (ASUD) originated as the National Register of Stratigraphic Names in 1949. The register was originally set up to help geoscientists adhere to the (then) newly created Australian Code of Stratigraphic Nomenclature (Lenz, et al, 1996). All information was held in a card file system until 1979 when the database was first developed electronically. The database now records information on all Australian stratigraphic units and their usage in literature, making it a centralised reference point for all Australian stratigraphic unit information. The database is also the repository for definition descriptions for these units. The database is maintained by Geoscience Australia in collaboration with the Geological Society of Australia's Australian Stratigraphy Commission. Dhx1 (talk) 10:22, 22 November 2015 (UTC)
- Discussion
- Support. Thryduulf (talk: local | en.wp | en.wikt) 21:30, 22 November 2015 (UTC)
- Comment Datatype needs to be string. Although the identifier is only a number we don't want any number formatting, or conversions. --Tobias1984 (talk) 08:58, 27 November 2015 (UTC)
- Comment Changed datatype to string, thanks Tobias1984. Dhx1 (talk) 13:08, 29 November 2015 (UTC)
- Done --Tobias1984 (talk) 13:17, 29 November 2015 (UTC)
FAO status
Description | FAO (united nation organisation about food) status of a race like abondance (Q322890) |
---|---|
Data type | Item |
Template parameter | « statut FAO » dans fr:Modèle:Infobox Race (in progress) |
Domain | breed (Q38829) |
Allowed values | FAO statuses : C (critical) / D (endangered) / CM (critical-maintened) / DM ( endangered-maintened) / X (extinct) / NAR (not at risk) / - (not enough datas). Items to be created. |
Example | |
Format and edit filter validation | (exemple : 7 chiffres peuvent être validés avec le filtre d'édition Special:AbuseFilter/17) |
Source | Hexasoft datas, FAO list |
Robot and gadget jobs | data import |
- Motivation
Is implemented into frwikis infobox, Wikidata usage on discussion. Datas from a United Nation organisation. author TomT0m / talk page 16:03, 3 November 2015 (UTC)
- Discussion
Support The name of the property should be FAO conservation status, in my opinion. Domain is wrong, and should be breed (Q38829). Allowed values should be the “FAO conservation status” item. C.f. Property_talk:P141. Tinm (talk) 18:12, 3 November 2015 (UTC)
- corrected author TomT0m / talk page
- Support. Joe Filceolaire (talk) 23:43, 3 November 2015 (UTC)
- Support Mirgolth (talk) 08:49, 4 November 2015 (UTC)
- Support Very useful data at all levels. Little risk of error due to the name (there's no latin name for domestic breeds) --Tsaag Valren (talk) 17:20, 4 November 2015 (UTC)
- Support Jérémy-Günther-Heinz Jähnick (talk) 09:32, 21 November 2015 (UTC)
Comment @TomT0m: This proposal looks well supported and I would like to create the property as my first experience at property creation :) However, a couple of things before I do that: (1) I think the name (en at least) should be "FAO risk status" - in the FAO documentation I looked at it seems to be referred to with that combination of terms most often, and I think that clarifies what it is for. (2) The target items need to be created - at the least the "not at risk" item for the example. I will go ahead and do that unless it's already been done. I'll probably work on this around 20 hours from now, so please make a note here if you have other ideas or want me to wait. Thanks! ArthurPSmith (talk) 22:02, 30 November 2015 (UTC)
Musopen composer identifier
Description | Musopen.org composer identifier |
---|---|
Represents | Musopen (Q2572292) |
Data type | String |
Domain | Persons |
Allowed values | text |
Example | Wolfgang Amadeus Mozart (Q254) => wolfgang-amadeus-mozart |
Source | https://musopen.org/music/ |
Formatter URL | https://musopen.org/composer/$1/ |
Robot and gadget jobs | could be added by bot since the identifiers in urls are consistent |
Proposed by | Wesalius (talk) |
- Discussion
Musopen.org hosts PD lincensed rercordings and sheet music of classical composers. Wesalius (talk) 12:48, 30 January 2015 (UTC)
- Comment actually Mozart is known as composer of recorded music https://musopen.org/music/composer/wolfgang-amadeus-mozart/ and as composer of sheet music https://musopen.org/sheetmusic/composer/wolfgang-amadeus-mozart/ and fortunately(?) the biographical sketches indicate that someone is aware of the two being the same person. -- Gymel (talk) 17:36, 24 February 2015 (UTC)
- I just noticed https://musopen.org/composer/wolfgang-amadeus-mozart/ dedicated to both (listing "most popular" entries). Thus the name forms are identical by design. -- Gymel (talk) 18:01, 24 February 2015 (UTC)
- formatter URL added. Is that the best choice? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:49, 6 March 2015 (UTC)
- I've added a trailing slash to the formatter URL, since https://musopen.org/composer/wolfgang-amadeus-mozart just redirects to https://musopen.org/composer/wolfgang-amadeus-mozart/ for me and I don't see any point in linking to something which redirects if it can easily be avoided. - Nikki (talk) 13:05, 1 May 2015 (UTC)
- Support. Runner1928 (talk) 18:12, 15 October 2015 (UTC)
@Wesalius, Gymel, Nikki, Runner1928: Done Musopen composer ID (P2338) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:45, 23 November 2015 (UTC)
World of Shakespeare ID
Description | page ID at World of Shakespeare website |
---|---|
Represents | Electronic Encyclopedia World of Shakespeare (Q19959941) |
Data type | String |
Template parameter | none, will be supported by Template:Authority control (Q3907614) in ruwiki |
Domain | any |
Allowed values | [0-9]+ |
Example | Vladimir Vysotsky (Q512) => 4284 |
Format and edit filter validation | shall be unique |
Source | ruwiki articles, site itself |
Formatter URL | http://www.world-shake.ru/ru/Encyclopaedia/$1.html |
Robot and gadget jobs | will be supported by "WEF: External Links" gadget |
- Motivation
Another good and reliable source. VlSergey (gab) 11:31, 21 May 2015 (UTC)
- Discussion
- Weak oppose To be clear, this is a (very) miniature version of what one may find on Wikipedia. I see a few issues with this specific website. 1. its title makes you think of everything about Shakespeare, but it's mainly where Russia intersects with Shakespeare, excluding most important information. 2. It still seems to be in its infancy and doesn't cover many topics, but does cover topics such as "Shakespeare in Russia." 3. The ID for the article in Russian is not the same ID for the article in English. For the example above, the English ID is 4360 (vs. 4284), so the URL is http://world-shake.ru/en/Encyclopaedia/4360.html. Nonetheless, if we only care about the Russian language section, this is moot. 4. I saw at least two likely copyright violations on the website, specifically with images. I only browsed a few pages so they may be the only ones. While it's not against policy as far as I know, it is still something we should keep in mind when linking to external sites. On the other hand, the site seems to be on the right track and has a plethora of references in each article, some inline, some not, so in some ways. Hazmat2 (talk) 22:47, 21 May 2015 (UTC)
- Oppose per above. Diego Grez-Cañete (talk) 05:16, 16 October 2015 (UTC)
Not done No support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 23 November 2015 (UTC)
Swedish Film Database
- On hold, see Wikidata:Properties for deletion.--GZWDer (talk) 16:04, 4 October 2015 (UTC)
- @GZWDer: Which section? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:58, 23 October 2015 (UTC)
- Wikidata:Properties for deletion#SFDb ID (OBSOLETE) (P1413). (t) Josve05a (c) 21:38, 23 October 2015 (UTC)
- Thank you. I see that resulted in consensus to delete P1413 (P1413), so these should no longer be "on hold". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:12, 24 October 2015 (UTC)
- Wikidata:Properties for deletion#SFDb ID (OBSOLETE) (P1413). (t) Josve05a (c) 21:38, 23 October 2015 (UTC)
- @GZWDer: Which section? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:58, 23 October 2015 (UTC)
Swedish Film Database film ID
Description | Swedish database of films |
---|---|
Represents | Swedish Film Database (Q1139587) |
Data type | String |
Template parameter | sfdb in sv:Mall:Filmfakta |
Domain | film (Q11424) |
Allowed values | numbers |
Example | Simple Simon (Q1659521) → 69473 |
Formatter URL | http://www.sfi.se/sv/svensk-filmdatabas/Item/?type=MOVIE&itemid=$1 |
- Motivation
Used widly on sv.wp and is a database of films and actors etc. (also see sv:Mall:SFDb; a common acronym used for this database is SFDb) (t) Josve05a (c) 22:28, 12 September 2015 (UTC)
- Discussion
- Support. Runner1928 (talk) 18:12, 15 October 2015 (UTC)
- Support --Steenth (talk) 15:31, 8 November 2015 (UTC)
Swedish Film Database company ID
Description | Swedish database of companies related to films |
---|---|
Represents | Swedish Film Database (Q1139587) |
Data type | String |
Allowed values | numbers |
Example | Anagram Produktion (Q10410032) → 348624 |
Formatter URL | http://www.sfi.se/sv/svensk-filmdatabas/Item/?type=COMPANY&itemid=$1 |
- Motivation
Used widly on sv.wp and is a database of films and actors etc. (also see sv:Mall:SFDb; a common acronym used for this database is SFDb) (t) Josve05a (c) 22:28, 12 September 2015 (UTC)
- Discussion
- Support. Runner1928 (talk) 18:12, 15 October 2015 (UTC)
- Support --Steenth (talk) 15:31, 8 November 2015 (UTC)
Swedish Film Database music ID
Description | Swedish database of music related to films |
---|---|
Represents | Swedish Film Database (Q1139587) |
Data type | String |
Allowed values | numbers |
Example | Titanic (Q10698747) → 2578 |
Formatter URL | http://www.sfi.se/sv/svensk-filmdatabas/Item/?type=MUSIC&itemid=$1 |
- Motivation
Used widly on sv.wp and is a database of films and actors etc. (also see sv:Mall:SFDb; a common acronym used for this database is SFDb) (t) Josve05a (c) 22:28, 12 September 2015 (UTC)
- Discussion
- Support. Runner1928 (talk) 18:12, 15 October 2015 (UTC)
- Support --Steenth (talk) 15:31, 8 November 2015 (UTC)
Swedish Film Database group ID
Description | Swedish database of groups related to films |
---|---|
Represents | Swedish Film Database (Q1139587) |
Data type | String |
Allowed values | numbers |
Example | ABBA (Q18233) → 173225 |
Formatter URL | http://www.sfi.se/sv/svensk-filmdatabas/Item/?type=GROUP&itemid=$1 |
- Motivation
Used widly on sv.wp and is a database of films and actors etc. (also see sv:Mall:SFDb; a common acronym used for this database is SFDb) (t) Josve05a (c) 22:28, 12 September 2015 (UTC)
- Discussion
- Support. Runner1928 (talk) 18:12, 15 October 2015 (UTC)
- Support --Steenth (talk) 15:31, 8 November 2015 (UTC)
BoardGameGeek ID
Description | ID number for a board game in BoardGameGeek |
---|---|
Template parameter | apparently none, but see en:Istanbul (board game)#External links, where en:Template:Bgg title is used |
Domain | board games (Q131436) |
Allowed values | numbers |
Source | external reference, Wikipedia list article, etc. |
Robot and gadget jobs | Possibly |
- Motivation
BoardGameGeek seems to be the database for board games. Palnatoke (talk) 09:06, 4 October 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 18:31, 6 October 2015 (UTC)
- Support. Widely used database and the primary database for this domain of information. Runner1928 (talk) 16:20, 13 October 2015 (UTC)
@Palnatoke, Filceolaire, Runner1928: Done BoardGameGeek ID (P2339). Datatype is "string". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:02, 23 November 2015 (UTC)
YSO identifier
Domain | any (but not people or purely geographical places, though there are some buildings, airports etc) |
---|---|
Robot and gadget jobs | Could be validated by dereferencing the URI and checking the resulting HTTP status code |
- Motivation
The General Finnish Ontology YSO is a trilingual ontology (and/or advanced thesaurus) consisting mainly of general concepts (about 27,000 currently). The National Library of Finland would like to start mapping YSO to Wikidata. We could also contribute some data from YSO, e.g. labels in Finnish, Swedish and/or English, to Wikidata once a mapping has been established. --Osma Suominen (talk) 13:45, 27 October 2015 (UTC)
- Discussion
- Support. Seems very appropriate. Runner1928 (talk) 14:24, 27 October 2015 (UTC)
- Support I adjusted the regex to match the description in filter. Popcorndude (talk) 22:29, 27 October 2015 (UTC)
- Thanks! After some thought I cut it down to max 5 digits because at the current rate of expansion, it would take decades to reach 6 digits. --Osma Suominen (talk) 15:37, 29 October 2015 (UTC)
@Osmasuominen, Runner1928, Popcorndude: Done YSO ID (P2347). And Osmasuominen - thank you; it's great to have contributions from institutions like yours. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 24 November 2015 (UTC)
Agorha IDs
IDs in Agorha a database maintained by Institut National d'Histoire de l'Art (Q3152376) and linking to other databases.
The website layout is a bit confusing, so I ping user:Shonagon who might know a bit more about this sort of things, but I think I can prpose three propertes as the permalink structure appears to be straightforward for these: --Zolo 5 nov / copiededited 8 nov 2015
Agorha person/institution ID
Description | identifier for a person or institution in the Agorha database |
---|---|
Data type | String |
Domain | humans or institutions |
Allowed values | integers |
Example | |
Formatter URL | http://www.purl.org/inha/agorha/002/$1 |
Robot and gadget jobs | mix'n'match |
Agorha work ID
Description | Agorha work ID |
---|---|
Data type | String |
Domain | works of art |
Allowed values | integers |
Example | Mona Lisa (Q12418) -> 12544 |
Formatter URL | http://www.purl.org/inha/agorha/003/$1 |
Robot and gadget jobs | mix'n'match |
Agorha event ID
Description | Agorha event ID |
---|---|
Data type | String |
Domain | events |
Allowed values | integers |
Example | Manet (Q15630512) -> 5121 |
Formatter URL | http://www.purl.org/inha/agorha/004/$1 |
Robot and gadget jobs | mix'n'match |
Proposal format
- @Zolo: Please complete the template for each of these nominations. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 5 November 2015 (UTC)
- @Pigsonthewing: once again, what's the point of adding
{{Property documentation}}
here ? It would not add any useful information, and would arguably blur the connection between the three proposed properties (perhaps we should just have one property or whatever). --Zolo (talk) 15:42, 6 November 2015 (UTC)- @Zolo: Once again, this was explained to you on 19 October, by User:Nikki. Your continued obstinacy in this matter is unbecoming of an admin. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 6 November 2015 (UTC)
- @Pigsonthewing: as you can see I had replied to Nikki at the time, and so had Jura. The template would not add anything relevant for this proposal, just translate a few words, so few that it couldn't possibly include more people in the discussion. You can't assume I will comply with your request if you are unable to provide a rationale. --Zolo (talk) 07:50, 7 November 2015 (UTC)
- @Zolo: Once again, this was explained to you on 19 October, by User:Nikki. Your continued obstinacy in this matter is unbecoming of an admin. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 6 November 2015 (UTC)
- @Pigsonthewing: once again, what's the point of adding
Oppose all due to malformed proposal.Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:22, 7 November 2015 (UTC)- Struck, now that the templates have been created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:58, 8 November 2015 (UTC)
- Interesting discussion! @Zolo: - I think you should go ahead and create those proper requests because that needs to be made in oder to complete the property (and the property will link back to this page). Not doing so just forces Andy to do it for you, which I just see as being impolite and putting the burden on the admin rather than the proposer. --Jane023 (talk) 10:05, 8 November 2015 (UTC)
- Andy has visibly no intention to add the template, and I am certainly not suggesting that he should. I would just like to know why it would be helpful to add it in this case. Afaik, the only recent discussion on the topic was in the mix'n'match section of Wikidata:Property proposal/Archive/39, and that was inconclusive at best.
- Now that there are statements on properties, mechanically copying the template from the proposal page should be avoided, as it adds a lot of redundant data that need to be cleaned up. If you look at the latest properties I created like Property talk:P2266, it does not reuse anything from the template from the discussion, nor should it. Had there be no template like here, things would have been done exactly the same way. --Zolo (talk) 10:53, 8 November 2015 (UTC)
- What seems even more problematic is that if you use the template, Pigsonthewing edits the content of the proposal template without noting the changes in the comments making it difficulte to determine what people agreed to (Diff). --- Jura 11:24, 8 November 2015 (UTC)
- Jura1 is upset because I fixed some formatting errors in a proposal he recently made. This is normal, and I reminded him on my talk page that he doesn't "own" the proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 8 November 2015 (UTC)
- I wasn't even involved in the proposal mentioned in the diff. --- Jura 13:55, 8 November 2015 (UTC)
- No-one said you were. The diff shows me in the process of cleaning up the template having created the property; as required by the appropriate process (Point 5 at Wikidata:Property creators#Steps when creating properties), and as every template creator should do. Nonetheless, my point about our recent interaction remains valid. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 8 November 2015 (UTC)
- I think you misunderstand the outlined process. Probably because you didn't attempt to follow it. Obviously, I disagree with you doing such edits. --- Jura 14:13, 8 November 2015 (UTC)
- No-one said you were. The diff shows me in the process of cleaning up the template having created the property; as required by the appropriate process (Point 5 at Wikidata:Property creators#Steps when creating properties), and as every template creator should do. Nonetheless, my point about our recent interaction remains valid. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 8 November 2015 (UTC)
- I wasn't even involved in the proposal mentioned in the diff. --- Jura 13:55, 8 November 2015 (UTC)
- Jura1 is upset because I fixed some formatting errors in a proposal he recently made. This is normal, and I reminded him on my talk page that he doesn't "own" the proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 8 November 2015 (UTC)
- Jane's point is valid, but it is not necessarily me who would have to do the work; whoever creates the property would have had to create the templates, due to Zolo's disruptive refusal to do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:58, 8 November 2015 (UTC)
- Let's be creative. Why not divide the process into two steps : formal acceptance after the initial discussion, then creation by the proposer of the required template as a required step before the creation ? A proposal is sometime not mature enough to create the template before discussion, and the template creation is a waste of time if the proposal is rejected. author TomT0m / talk page 14:07, 8 November 2015 (UTC)
- Because that would deprive us of the benefits of using the template from the outset; and because there is no guarantee that a proponent would return to carry out such a task; or if they did, that they would do so in a timely manner. When used properly, the current process works well (further: no cogent argument has been made that it does not; much else evidence been provided). But again, you are welcome to make such a proposal in the appropriate place, for the community to consider. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:56, 8 November 2015 (UTC)
- @Pigsonthewing: Seriously, you really think that there is evidences that all this process works fine ? Well, just compare the number of infoboxes not migrated yet ... This is so sloooooow ... I can show proposals of mine a year old ... I could read mockeries of wikipedians mock the bureaucraty required to create a single property. author TomT0m / talk page 20:02, 8 November 2015 (UTC)
- Please explain how not using the template would improve the issues you describe - or indeed how u`sing it causes them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:02, 9 November 2015 (UTC)
- @Pigsonthewing: Seriously, you really think that there is evidences that all this process works fine ? Well, just compare the number of infoboxes not migrated yet ... This is so sloooooow ... I can show proposals of mine a year old ... I could read mockeries of wikipedians mock the bureaucraty required to create a single property. author TomT0m / talk page 20:02, 8 November 2015 (UTC)
- Because that would deprive us of the benefits of using the template from the outset; and because there is no guarantee that a proponent would return to carry out such a task; or if they did, that they would do so in a timely manner. When used properly, the current process works well (further: no cogent argument has been made that it does not; much else evidence been provided). But again, you are welcome to make such a proposal in the appropriate place, for the community to consider. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:56, 8 November 2015 (UTC)
- Let's be creative. Why not divide the process into two steps : formal acceptance after the initial discussion, then creation by the proposer of the required template as a required step before the creation ? A proposal is sometime not mature enough to create the template before discussion, and the template creation is a waste of time if the proposal is rejected. author TomT0m / talk page 14:07, 8 November 2015 (UTC)
- What seems even more problematic is that if you use the template, Pigsonthewing edits the content of the proposal template without noting the changes in the comments making it difficulte to determine what people agreed to (Diff). --- Jura 11:24, 8 November 2015 (UTC)
This is a waste of time and energy. I just added the templates. Please do come up with a better way of handling this in the future, but not here. Probably better to move this to Wikidata talk:Property proposal. Maybe create a template like {{Proposed property}}
in which you fill out all the information. Once you created the property the template will suggest the missing claims to be added and the contents of the {{Property documentation}}
to be added to the talk page. Multichill (talk) 11:54, 8 November 2015 (UTC)
- Thanks for doing it, I have copied that to Wikidata talk:Property proposal--Zolo (talk) 13:41, 8 November 2015 (UTC)
- The better way of handling this is for Zolo to use the standard template in his proposals; as he has been requested to do several times, and not just by me. He is disrupting this page to make a point. If he thinks the template is subomptimal, he is welcome to suggest changes to it (or indeed, its deletion), in order that the community can reach consensus as to whether those changes should be made; or whether the previous consensus, which resulted in this template, holds. Both he and you are admins, and so should be aware that this is how Wikidata works. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 8 November 2015 (UTC)
- Better pursue this off-topic discussion at Wikidata talk:Property proposal. Just some quick clarifications as I find your reaction really puzzling. I have no wish to change the property documentation template. The way Wikidata works is that we need not follow rules when none was ever decided, and none was for the property proposal format. Prior to this discussion, only one other user said we I should have added the template. I had explained why I had not, and a third user supported me, and nothing beyond that. Were it not for your puzzling reaction, there would not have been much disruption. Ok that's all for me here. --Zolo (talk) 23:29, 8 November 2015 (UTC)
- Consensus clearly exists for the process (including use of the template) outlined at the top of this and all its sister pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:09, 9 November 2015 (UTC)
Discussion
- Notified participants of WikiProject Visual arts any view on these proposals ? --Zolo (talk) 08:09, 8 November 2015 (UTC)
- @Pigsonthewing: : I think we need to talk about how to handle these. We already have RKDartist and RKDimages and others from the RKD like Depeicts Iconclass notation, etc. I think there should be some way to connect these so that users are 1) not confused when they select a property and 2) users can easily see the connections. Most large image databases for art will include a separate index for artists, and each is a gateway to the other. We need a better way to handle these. I discussed this a bit yesterday with @Spinster: because we are thinking about addling lots of properties for museum collections that also have similar constructs, including exhibitions or publications. Perhaps we could figure some property that would combine all of them and if used on an item already sorts to the proper sub-property based on the type of item. --Jane023 (talk) 10:05, 8 November 2015 (UTC)
- Note: I'v taken the libery to reorganize the discussion for readability. --Zolo (talk) 10:53, 8 November 2015 (UTC)
- @Jane023: indeed if we go on the current way, like with Museum of Modern Art work ID (P2014)-Museum of Modern Art artist ID (P2174) many more properties will be created. I am not sure it is really a problem though. Now that we can add statements on properties, things are relatively easy to monitor. --Zolo (talk) 10:53, 8 November 2015 (UTC)
- We noticed there was a problem with the RKDI database on Mix-n-Match - most of the automatches are incorrect - presumably these have been matched incorrectly (or something went wrong when the database was loaded by Magnus). The issue occurs at the moment the user selects the property. You need to look not just for RKD but also the suffix (@Jheald: discussed user notes for this recently on the Wikidata mailing list). --Jane023 (talk) 11:01, 8 November 2015 (UTC)
- I think it's probably essential to have different properties, because they have different formatters. It would be horrible to have to work out the type of a thing before you could format its URL. It also would very confusing, if the numerical ranges overlap, to have the same value on a single property apparently applying to a number of different things (and make it harder to implement "unique value" constraint violations).
- At the moment we have Art UK artist ID (P1367), Art UK collection ID (P1751), Art UK venue ID (P1602) and Art UK artwork ID (P1679). Those don't appear to have caused any difficulty with data entry; and most uses of a wrong property on a particular kind of item will trigger a constraint violation. There may be a problem if the number of properties associated with a particular institution becomes larger than the size of the drop-down box, but we've not reached that extent here. Jheald (talk) 11:11, 8 November 2015 (UTC)
- It would be possible to have one formatter (http://www.purl.org/inha/agorha/$1) and the id's look like 002/112086. I don't think that would be a good plan. Support creation of these properties. Multichill (talk) 11:54, 8 November 2015 (UTC)
- Support creation of the separate properties as proposed at the time of my signature. Useful databases. Spinster (talk) 17:01, 8 November 2015 (UTC)
- Support to create separate props. EAGLE id (P1900) uses a single namespace for different kinds of IDs, so their IDs are of the form "objtyp/lod/x" vs "material/lod/y", etc. I don't like the result (incl. the parasitic word "LOD").
- Propose to rename to "FR Agorha ... ID" (including the country code)
- Agree with @Jane023: that this proliferation of props calls for some reorganization in the future. The formatter can take 2 params: authority and kind, and for each authority we need a table which kinds it supports. But this will make adding instances so much more difficult. (Note: don't call this "sub-properties" or you'll make a big confusion with rdfs:subPropertyOf). --Vladimir Alexiev (talk) 10:15, 9 November 2015 (UTC)
- Support High-scientific value of the database (edited by curators, up to date, bibliographic references), a large scope with a meta-collection approach, permalinks with purl. --Shonagon (talk) 12:30, 10 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 08:20, 11 November 2015 (UTC)
- Notified participants of WikiProject Visual arts, @Zolo, Filceolaire, Shonagon, Vladimir Alexiev, Jane023, Spinster: Done. — Ayack (talk) 13:50, 24 November 2015 (UTC)
Speedskatingbase.eu ID
Template parameter | id in w:no:Template:Speedskatingbase |
---|---|
Domain | human |
Robot and gadget jobs | could be added to mix'n'match |
- Motivation
49696 entries, could be used to expand items about speed skaters. Sjoerd de Bruin (talk) 19:11, 11 November 2015 (UTC)
- Discussion
- Support. There should be personal best times for the most of notable speed skaters on Wikipedia, although the site has set some time-limits for inclusion, so it might exclude some few from the early period of speed skating round the year of 1900. I really think it is a great resource for speed skater articles. Migrant (talk) 19:34, 11 November 2015 (UTC)
- On the norwegian wikipedia I have created a Template for the ID: (Speedskatingbase (in NO:WP – Norwegian language)). Hopefully it can be of help with importing values to spread the information faster. Migrant (talk) 21:02, 11 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 16:19, 14 November 2015 (UTC)
- Support. Knuteinar2309 (talk) 22:36, 14 November 2015 (UTC)
@Sjoerddebruin, Migrant, Filceolaire, Knuteinar2309: Done SpeedSkatingBase.eu ID (archived) (P2350) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:43, 24 November 2015 (UTC)
Elonet ID for a movie
Template parameter | Wikipedia infobox parameters, "Elonet" parameter in the movie template |
---|
Elonet is a web version of The Finnish National Filmography. Useful. Stryn (talk) 14:42, 13 November 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 16:26, 14 November 2015 (UTC)
- Support. Máté (talk) 06:50, 16 November 2015 (UTC)
@Stryn, Filceolaire, Máté: Done Elonet movie ID (P2346) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 24 November 2015 (UTC)
UNESCO endangered language ID
Domain | Languages ( items with instance of (P31) language (Q34770) ) |
---|---|
Allowed values | String pattern: Only numerical characters |
- Motivation
We have been given access to the endangered languages list by UNESCO, and this property will allow us to match languages on the list to Wikidata items using Mix 'n' Match. Also allows links to be generated to the individual languages pages on the UNESCO website NavinoEvans (talk) 17:39, 19 November 2015 (UTC)
- Discussion
- Support Runner1928 (talk) 19:05, 19 November 2015 (UTC)
- Support Joe Filceolaire (talk) 06:56, 24 November 2015 (UTC)
@NavinoEvans, Runner1928, Filceolaire: Done UNESCO Atlas of the World's Languages in Danger ID (P2355) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:21, 26 November 2015 (UTC)
AIATSIS Code
Description | Language code in the Australian Indigenous Languages Database (AUSTLANG) maintained by the Australian Institute of Aboriginal and Torres Strait Islander Studies (AIATSIS) |
---|---|
Represents | Australian Aboriginal languages (Q205143) |
Data type | String |
Template parameter | "aiatsis" in en:template:infobox language |
Domain | language (Q315) |
Allowed values | String pattern: [A-Z]\d+(\.(\d+|[A-Z]+))?\*? |
Example | Arabana (Q3507959) → L13 |
Source | Australian Indigenous Languages Database maintained by the Australian Institute of Aboriginal and Torres Strait Islander Studies |
Formatter URL | http://austlang.aiatsis.gov.au/main.php?code=$1 |
Robot and gadget jobs | AIATSIS Codes could be scraped from the Australian Indigenous Languages Database, and mix-and-match used to import into Wikidata |
- Motivation
The Australian Aboriginal languages comprise up to twenty-seven language families and isolates native to the Australian Aborigines of Australia. In the late 18th century, there were between 350 and 750 distinct Aboriginal social groupings, and a similar number of languages or dialects. At the start of the 21st century, fewer than 150 Indigenous languages remain in daily use, and all except roughly 20 are highly endangered. The Australian Institute of Aboriginal and Torres Strait Islander Studies (AIATSIS) is an independent Australian Government statutory authority. It is a collecting, publishing and research institute and is considered to be Australia's premier resource for information about the cultures and societies of Aboriginal and Torres Strait Islander peoples. AUSTLANG is therefore perhaps the best catalogue of Aboriginal languages. Dhx1 (talk) 03:06, 22 November 2015 (UTC)
- Discussion
- Support Joe Filceolaire (talk) 07:02, 24 November 2015 (UTC)
- Support NavinoEvans (talk) 12:47, 26 November 2015 (UTC)
- Support Runner1928 (talk) 15:03, 26 November 2015 (UTC)
- Question What is the difference with AUSTLANG code (P1252) ? Visite fortuitement prolongée (talk) 21:09, 26 November 2015 (UTC)
Not done - AUSTLANG code (P1252) already exists, with the same formatter URL and alias. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 26 November 2015 (UTC)
- Oops, didn't see AUSTLANG code (P1252) as already existing, I must have searched incorrectly. Thanks for finding the duplicate, and apologies for wasting time. Dhx1 (talk) 01:01, 27 November 2015 (UTC)
Classification of Instructional Programs code
Domain | academic discipline (Q11862829) |
---|---|
Robot and gadget jobs | import from freely available database, United States Department of Education (Q861556) |
- Motivation
"The Classification of Instructional Programs (CIP) provides a taxonomic scheme that supports the accurate tracking and reporting of fields of study and program completions activity. CIP was originally developed by the U.S. Department of Education's National Center for Education Statistics (NCES) in 1980, with revisions occurring in 1985, 1990, and 2000." The current CIP is from the year 2010. This is the official taxonomy of educational fields of study for the US government, and all colleges and universities have to report graduates based on these values. CIP codes are also hierarchical: 01 is agriculture (Q11451), 01.09 is animal science (Q168091), and 01.0906 is animal nutrition science (Q4764962). This directly maps to Wikidata's instance of (P31) and subclass of (P279) schema. With this data, and creating missing academic discipline (Q11862829) entities, we can better support academic major (P812) as well. Runner1928 (talk) 19:02, 11 November 2015 (UTC)
- Discussion
- Support This certainly seems useful. ArthurPSmith (talk) 19:40, 11 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 14:45, 12 November 2015 (UTC)
@Runner1928, ArthurPSmith, Filceolaire: Done Classification of Instructional Programs code (P2357) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:45, 26 November 2015 (UTC)
Soccerway player id
Description | Player id on the Soccerway website |
---|---|
Data type | String |
Template parameter | |1= or |id= in en:Template:Soccerway; equivalent templates in other language Wikipedias |
Domain | human |
Example | Javier Savioler (Q186071) → javier-saviola/121 |
Source | Wikipedia templates or searching the website |
Formatter URL | http://www.soccerway.com/players/$1 |
Robot and gadget jobs | Bots could import from templates |
- Motivation
Soccerway is a website that gives information, results and statistics about domestic and international soccer. We also have templates in quite a few Wikipedias with apparently equivalent templates, that could potentially be imported from. Silverfish (talk) 23:56, 31 October 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 06:46, 24 November 2015 (UTC)
- Done @Silverfish, Filceolaire: Created as Property:P2369. Jon Harald Søby (talk) 12:43, 1 December 2015 (UTC)
ODIS ID
Description | Identifiers in the Belgian ODIS (Q3956431) database |
---|---|
Data type | String |
Domain | person, organization, event, building |
Allowed values | string of letters and numbers.
|
Example | Jos De Swerts (Q2465723) → PS_21852 |
Source | http://www.odis.be/hercules/advancedSearch.php |
Formatter URL | http://www.odis.be/lnk/$1 |
Robot and gadget jobs | Would be great to be included in Mix'n'Match |
- Motivation
Extensive database of important people and organizations in Belgium's social and cultural history. I found ~8,200 organizations, 22 families (not sure how relevant these are), 122 events, ~2,000 buildings (mostly churches), ~43,000 persons. Spinster (talk) 17:55, 8 November 2015 (UTC)
- Discussion
- Support Runner1928 (talk) 20:03, 8 November 2015 (UTC)
- Support but propose to rename to "BE ODIS ID" --Vladimir Alexiev (talk) 10:18, 9 November 2015 (UTC)
- Comment I don't mind renaming - I understand that ODIS might be an often-used acronym. However, for findability purposes during Wikidata editing I'd prefer odis.be ID (keep the acronym first). Spinster (talk) 10:31, 11 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 08:19, 11 November 2015 (UTC)
@Spinster, Runner1928, Vladimir Alexiev, Filceolaire: Done ODIS ID (P2372) — Ayack (talk) 11:23, 2 December 2015 (UTC)
CESAR person ID
Domain | people |
---|---|
Allowed values | 6 digits |
Robot and gadget jobs | mix'n'match? |
7023 persons. — Ayack (talk) 19:52, 8 November 2015 (UTC)
- Discussion
- Support Runner1928 (talk) 20:04, 8 November 2015 (UTC)
- Support Magnus Manske (talk) 10:54, 9 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 08:17, 11 November 2015 (UTC)
@Ayack, Runner1928, Magnus Manske, Filceolaire: Done CESAR person ID (P2340) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 23 November 2015 (UTC)
Database of Scientific Illustrators ID
Domain | deceased humans; illustrators of scientific publications of all genres (especially atlases, articles, textbooks) |
---|---|
Source | external reference, Wikipedia list article, etc. |
Robot and gadget jobs | Currently in Mix'n'match (~2000 identified) |
- Motivation
The Stuttgart Database of Scientific Illustrators 1450–1950 (Q21417186) includes records of "more than 10400 illustrators in natural history, medicine, technology and various sciences in more than 100 countries, active between c.1450 and 1950". As shown by the example given above, it includes URLs for Wikipedia articles; and VIAF IDs. Other entries include Wikimedia Commons URLs. One this property is created, I will ask the University to provide a data dump which we can parse for such URLs; and once we have parsed and imported them, invite the University to also include Wikdiata IDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:28, 9 November 2015 (UTC)
- Discussion
- Support Magnus Manske (talk) 13:30, 9 November 2015 (UTC)
- Support --Daniel Mietchen (talk) 14:05, 9 November 2015 (UTC)
- Support. Joe Filceolaire (talk) 08:18, 11 November 2015 (UTC)
- Support, looks good (will remove duplicate request). Andrew Gray (talk) 21:02, 24 November 2015 (UTC)
@Magnus Manske, Daniel Mietchen, Filceolaire, Andrew Gray: Done Stuttgart Database of Scientific Illustrators ID (P2349) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:17, 24 November 2015 (UTC)
chemical exposure properties
recommended time-weighted average exposure limit
Description | non-binding recommended concentration for chemical exposure in a workplace in a given work day |
---|---|
Represents | time-weighted average concentration (Q21010836) |
Data type | Number (not available yet) |
Domain | chemicals |
Allowed values | any number with a concentration measurement such as gram per litre (Q834105); duration (i.e. length of workday used in measurement) maintained by (P126) as qualifier |
Example | butyl acetate (Q411073) → 0.00071 gram per litre (Q834105); maintained by (P126) → National Institute for Occupational Safety and Health (Q60346); duration → 10 hour (Q25235) |
Source | NIOSH pocket guide to chemical hazards, 2005 edition, 3rd printing (Q20022913) for U.S. values; potentially other sources as well |
Robot and gadget jobs | Part of mass importation of the Pocket Guide to Chemical Hazards into Wikidata. |
- Motivation
James Hare (NIOSH) (talk) 20:22, 21 October 2015 (UTC)
- This proposal has been made obsolete. James Hare (NIOSH) (talk) 15:05, 1 December 2015 (UTC)
- Discussion
- See general discussion at the head of this section Joe Filceolaire (talk) 00:57, 4 November 2015 (UTC)
James: While the NIOSH limits may be non-binding recommendations, other countries may have legally binding limits. Will this property be usable for both cases? Joe Filceolaire (talk) 01:40, 4 November 2015 (UTC)Oops. Just noticed the the legal limit property just above. Joe Filceolaire (talk) 01:42, 4 November 2015 (UTC)
recommended ceiling exposure limit
Description | non-binding recommended maximum concentration for chemical exposure in a given work day |
---|---|
Represents | ceiling concentration (Q21010844) |
Data type | Number (not available yet) |
Domain | chemicals |
Allowed values | any number with a concentration measurement such as gram per litre (Q834105); maintained by (P126) as qualifier; duration and route of administration (P636) as optional qualifiers |
Example | acetylene (Q133145) → 0.002662 gram per litre (Q834105); maintained by (P126) → National Institute for Occupational Safety and Health (Q60346) |
Source | NIOSH pocket guide to chemical hazards, 2005 edition, 3rd printing (Q20022913) for U.S. values; potentially other sources as well |
Robot and gadget jobs | Part of mass importation of the Pocket Guide to Chemical Hazards into Wikidata. |
- Motivation
James Hare (NIOSH) (talk) 20:22, 21 October 2015 (UTC)
- This proposal has been made obsolete. James Hare (NIOSH) (talk) 15:06, 1 December 2015 (UTC)
- Discussion
- See general discussion at the head of this section Joe Filceolaire (talk) 00:57, 4 November 2015 (UTC)
recommended short-term exposure limit
Description | non-binding recommended concentration for chemical exposure during a brief time window |
---|---|
Represents | short-term exposure limit (Q7501690) |
Data type | Number (not available yet) |
Domain | chemicals |
Allowed values | any number with a concentration measurement such as gram per litre (Q834105); maintained by (P126) and duration as qualifiers |
Example | butyl acetate (Q411073) → 0.00095 gram per litre (Q834105); maintained by (P126) → National Institute for Occupational Safety and Health (Q60346); duration → 15 minute (Q7727) |
Source | NIOSH pocket guide to chemical hazards, 2005 edition, 3rd printing (Q20022913) for U.S. values; potentially other sources as well |
Robot and gadget jobs | Part of mass importation of the Pocket Guide to Chemical Hazards into Wikidata. |
- Motivation
James Hare (NIOSH) (talk) 20:22, 21 October 2015 (UTC)
- This proposal has been made obsolete. James Hare (NIOSH) (talk) 15:06, 1 December 2015 (UTC)
- Discussion
- See general discussion at the head of this section Joe Filceolaire (talk) 00:57, 4 November 2015 (UTC)
R phrase
Description | EU risk phrases for chemical safety |
---|---|
Data type | String |
Template parameter | RPhrases in en.wp chembox |
Domain | chemicals |
Allowed values | String beginning with R, ending in numbers |
Example | 1,2-Dibromo-3-chloropropane -> R45, R46, R60, R25, R48/20/22, R52/53 |
Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Source | external references |
Robot and gadget jobs | Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.) |
- Motivation
Widely used infobox paramter on en.wp, should be indexed in Wikidata. Emily Temple-Wood (NIOSH) (talk) 18:54, 22 October 2015 (UTC)
- Discussion
- Oppose S phrases are not more valid as labeling according to EU regulation. Starting June 2015 only GHS labels are used. All values about S phrases are deprecated and I don't think this is the job of WD to archive all deprecated values especially when they are imported as deprecated. Snipre (talk) 08:28, 23 October 2015 (UTC)
- This statement is partly incorrect. Mixtures classified, labelled, packaged already placed on the market before 1 June 2015 are not required to be relabelled and repackaged in accordance with the CLP Regulation until 1 June 2017. Even after that date, articles such as cleaning products may be found in many households. --Leyo 01:31, 17 November 2015 (UTC)
- If you want to play with the words but you can't discuss the fact that starting June 2015 the GHS is the unique labelling system valid in EU (see ECHA, first lines: "From 1 June 2015, the Classification, Labelling and Packaging (CLP) Regulation will be the only legislation to apply to the classification and labelling of both substances and mixtures.". What you mentioned is a transient agreement for chemicals produced before the date. Temporary exception due to logistic reality doesn't modify the facts that you can't produces any chemical with the old label even if you can ensure the use of this product before 2017 and that all modifications of labelling between July 2015 and now are not more translated in the old system). Snipre (talk) 02:51, 17 November 2015 (UTC)
- This statement is partly incorrect. Mixtures classified, labelled, packaged already placed on the market before 1 June 2015 are not required to be relabelled and repackaged in accordance with the CLP Regulation until 1 June 2017. Even after that date, articles such as cleaning products may be found in many households. --Leyo 01:31, 17 November 2015 (UTC)
- Oppose same reason --Almondega (talk) 11:54, 2 November 2015 (UTC)
- Oppose. Though I do think we should create items for every S and R phrase so that when you find a bottle covered in dust at the back of the cupboard you can find out what it meant back in the day. What we should not do is give obsolete info on the items for the chemicals. Joe Filceolaire (talk) 01:12, 4 November 2015 (UTC)
- We can always use the rank deprecated to specify that the values are not more valid but I think we should keep the deprecated rank to filter data in the case where some are at least valid and some not. If R and S phrases were absolute we could do it but as safety data is improving with time these data are relative to a special system and a defined knowledge at time t. Snipre (talk) 12:58, 4 November 2015 (UTC)
Not done no support --Pasleim (talk) 23:34, 28 November 2015 (UTC)
S phrase
Description | EU safety phrases for chemical safety |
---|---|
Data type | String |
Template parameter | SPhrases in en.wp chembox |
Domain | chemicals |
Allowed values | String beginning with S, ending in numbers |
Example | 1,2-Dibromo-3-chloropropane -> S53, S45, S61 |
Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Source | external references |
Robot and gadget jobs | Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.) |
- Motivation
Widely used infobox paramter on en.wp, should be indexed in Wikidata. Emily Temple-Wood (NIOSH) (talk) 18:55, 22 October 2015 (UTC)
- Discussion
- Oppose S phrases are not more valid as labeling according to EU regulation. Starting June 2015 only GHS labels are used. All values about S phrases are deprecated and I don't think this is the job of WD to archive all deprecated values especially when they are imported as deprecated. Snipre (talk) 08:28, 23 October 2015 (UTC)
- Oppose same reason --Almondega (talk) 11:55, 2 November 2015 (UTC)
- See comment above. --Leyo 01:34, 17 November 2015 (UTC)
- Not done no support --Pasleim (talk) 23:35, 28 November 2015 (UTC)
antagonist muscle
Description | ... |
---|---|
Data type | Item |
Template parameter | "Antagonist" in en:template:infobox muscle |
Domain | muscles |
Allowed values | text |
Example | biceps femoris muscle (Q601016) → quadriceps femoris muscle (Q504536) |
Source | infobox muscle parameter |
- Motivation
These paired relations between muscles and their antagonists are well-defined, and currently absent. --Wesalius (talk) 06:38, 10 November 2015 (UTC)
Support Seems reasonable and useful --I9606 (talk) 16:15, 10 November 2015 (UTC)
- Discussion
Notified participants of WikiProject Medicine
- Support --Tobias1984 (talk) 21:47, 10 November 2015 (UTC)
- Tobias1984, will you create this property now? --Wesalius (talk) 15:07, 21 November 2015 (UTC)
- Support Makes sense. -- emitraka (talk) 16:09, 11 November 2015 (UTC)
applies to taxon
Description | qualifier for toxicological concentrations and doses, indicates species in which the drug was tested |
---|---|
Data type | Item |
Template parameter | "LD50" in en:Template:Chembox_Hazards |
Domain | molecular entity (Q2393187), e.g. chemical substance (Q79529), chemical compound (Q11173), medication (Q12140), cation (Q326277), anion (Q107968), mixture (Q169336) . |
Allowed values | taxon (Q16521) |
Example | potassium cyanide (Q192470) → median lethal dose (LD50) (P2240) (11 mg/kg) → route of administration (P636) (subcutaneous injection (Q2035485)) + species (house mouse (Q83310)) |
Source | safety data sheet (Q222067), section 11 |
Proposed by | Almondega (talk) 14:43, 12 October 2015 (UTC) |
- Motivation
Wikidata qualifier (Q18615010) of median lethal dose (LD50) (P2240).
Notified participants of WikiProject Chemistry
Notified participants of WikiProject Medicine--Almondega (talk) 14:27, 12 October 2015 (UTC)
- Discussion
- Comment @Almondega: I think a different label would be good, because we don't always link to the species of the animal (also genus etc.). Also there would be the danger of users misusing it as a property and causing problems with the taxonomy properties. Would "animal model" or "model animal" be the better name? Maybe even "observed in animal model"? --Tobias1984 (talk) 17:39, 12 October 2015 (UTC)
- or simply taxon ? Assuming species or genus are kind of taxons. Animal would suggest it's to link to an instance of animal. author TomT0m / talk page 17:43, 12 October 2015 (UTC)
- @TomT0m: I think longer labels are much easier to understand in a semantic database, because the claims then complete a sentence. "Taxon" "Mouse" means almost nothing in my opinion. And using labels that are close to taxonomy, will result in more conflicts. For example the item Citrus × limon (Q500) can be viewed from a food or taxonomy perspective. But we can only have one label, so the conflict is between "Citrus ×limon" and "lemon". Similar for chemical compounds that are also used in pharmaceutics. People would use a property "taxon" for a lot of different things. Especially with the qualifiers I tend to think we should provide unambigeous clarity. --Tobias1984 (talk) 18:00, 12 October 2015 (UTC)
- @Tobias1984: "applies to taxon" then. I can understand the need of clear guideline, I'm a little bit more skeptical on having a lot of very closely called properties because it leads to more confusion of one each other. We have a lot of questions "which property should I use, this one or that one ?",
- @TomT0m: I think longer labels are much easier to understand in a semantic database, because the claims then complete a sentence. "Taxon" "Mouse" means almost nothing in my opinion. And using labels that are close to taxonomy, will result in more conflicts. For example the item Citrus × limon (Q500) can be viewed from a food or taxonomy perspective. But we can only have one label, so the conflict is between "Citrus ×limon" and "lemon". Similar for chemical compounds that are also used in pharmaceutics. People would use a property "taxon" for a lot of different things. Especially with the qualifiers I tend to think we should provide unambigeous clarity. --Tobias1984 (talk) 18:00, 12 October 2015 (UTC)
- or simply taxon ? Assuming species or genus are kind of taxons. Animal would suggest it's to link to an instance of animal. author TomT0m / talk page 17:43, 12 October 2015 (UTC)
so I think it actually would not hurt that taxonomy and this field would share a property if the only difference in their use is the field they apply to. Imagine in molecular biology that a protein or some hormon has a specific effect on some kind on animal, or if in taxonomy one has to specify on which taxon a claim is valid, what's the harm to use this qualifier ? How useful would it be to create qualifier "applies to taxon but only if the claim is in the taxonomy" and "applies to taxon if we're talking about a drug" ? author TomT0m / talk page 18:15, 12 October 2015 (UTC)
- I concur with Tobias1984 that 'species' is far to broadly used a term in other senses to bind it to a property with this specificity. I also think that TomT0m is right to shoot for properties that are fairly general and multi-purpose at this stage in the game. I think a qualifier "applies to taxon" would work for this particular application and would be generally useful in other biological settings. --I9606 (talk) 18:45, 12 October 2015 (UTC)
Comment One more : you might want to replace the main snak of all this, and make the taxon the main value of the claim. There is potentially, I guess, various type of doses that might apply to the same taxon, lethal dose, mean journal dose, I don't know. Maybe it would make sense to regroup all this kind of doses in the same statement. This would give something like
lethal dose Search ⟨ the dose ⟩
recommanded dose Search ⟨ another dose ⟩
. With the benefit that the rule of thumb "the main snak should make sense by itself" would be fulfilled. author TomT0m / talk page 19:22, 12 October 2015 (UTC)
- How about "established in taxon"? - Brya (talk) 04:10, 13 October 2015 (UTC)
: Support @TomT0m: I think the structure you proposed would be really better. In this case, the median lethal dose (LD50) (P2240) would be a qualifier of this property "can be given to taxon". --Almondega (talk) 12:41, 19 October 2015 (UTC) Question @TomT0m:In this structure, as may be specified route of administration (P636)? --Almondega (talk) 13:09, 19 October 2015 (UTC)
- @Almondega: You mean "how" ? I guess the same way as a qualifier would also work. If there is alternatives to give the chemical, another statement would do the trick. author TomT0m / talk page 17:16, 19 October 2015 (UTC)
- Support --Almondega (talk) 17:22, 19 October 2015 (UTC)
- @TomT0m, Almondega: The problem of combined values structure is the references when several values for the same specie/taxon come from several sources. Snipre (talk) 12:31, 3 November 2015 (UTC)
- Support --Almondega (talk) 17:22, 19 October 2015 (UTC)
- @Snipre: So, how do you consider the best way to enter this information? --Almondega (talk) 12:41, 3 November 2015 (UTC)
- Like a qualifier for lethal dose or lethal concentration properties. For example, for lethal concentration properties we need the specie/taxon and the duration of the exposition so the proposed structure doesn't allow to have qualifier for qualifier.
- 50 lethal dose (property): 50 mg/kg (value)
- specie/taxon (qualifier): rabbit (value)~
- route of administration (P636) (qualifier): oral (value)
- 50 lethal concentration (property): 50 mg/l (value)
- specie/taxon (qualifier): rabbit (value)
- duration (qualifier): 20 min (value)
- route of administration (P636) (qualifier): inhalation (value)
- Snipre (talk) 13:20, 3 November 2015 (UTC)
- What solves this is to make one statement per source (that might give several numbers anyway). So this can be done as well with the previous model. With better "visual search" property because the dose does not mean anything without the species. author TomT0m / talk page 13:24, 3 November 2015 (UTC)
- @Snipre: So, how do you consider the best way to enter this information? --Almondega (talk) 12:41, 3 November 2015 (UTC)
- Support but change the name to 'applies to taxon'. I think the structure proposed by Snipre is the way to record lethal dose/concentration and we should create those additional properties. Joe Filceolaire (talk) 02:26, 4 November 2015 (UTC)
- @Almondega, Tobias1984, I9606: Any comment about the last proposition (property name and data structure) ? I think we have a solution and we can go ahead win the creation process. Snipre (talk) 13:56, 13 November 2015 (UTC)
- WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Unless anyone from WikiProject Taxanomy has some concerns I will create this property with the English label "applies to taxon" tomorrow. --Tobias1984 (talk) 14:42, 13 November 2015 (UTC)
- I remain uncomfortable with the label "applies to taxon"; it sounds like something that can be used in many circumstances. If the intent is as stated ("indicates [taxon] in which the drug was tested") then "established in taxon" would be better, although I would not want to claim this is necessarily the optimum wording. - Brya (talk) 17:32, 13 November 2015 (UTC)
- @Brya, Snipre, Tobias1984: I see no problem in this qualifier be used in other circumstances in which a qualifier "applies to taxon" is useful. --Almondega (talk) 01:03, 14 November 2015 (UTC)
- Maybe not. I just hope it does not cause confusion. - Brya (talk) 09:07, 14 November 2015 (UTC)
- @Brya, Snipre, Tobias1984: I see no problem in this qualifier be used in other circumstances in which a qualifier "applies to taxon" is useful. --Almondega (talk) 01:03, 14 November 2015 (UTC)
- I remain uncomfortable with the label "applies to taxon"; it sounds like something that can be used in many circumstances. If the intent is as stated ("indicates [taxon] in which the drug was tested") then "established in taxon" would be better, although I would not want to claim this is necessarily the optimum wording. - Brya (talk) 17:32, 13 November 2015 (UTC)
- We need a property creator. @Jonathan Groß: ? Snipre (talk) 15:40, 25 November 2015 (UTC)
- @Snipre: not today and not until next week, I'm afraid ... I'll be abroad. Jonathan Groß (talk) 16:34, 25 November 2015 (UTC)
- I will create this one. Danrok (talk) 21:08, 25 November 2015 (UTC)
Köppen–Geiger climate classification system
Description | Köppen climate classification is one of the most widely used climate classification systems. It was first published by Russian German climatologist Wladimir Köppen in 1884, with several later modifications by Köppen himself, notably in 1918 and 1936. Later, German climatologist Rudolf Geiger collaborated with Köppen on changes to the classification system, which is thus sometimes referred to as the Köppen–Geiger climate classification system. |
---|---|
Represents | Köppen climate classification (Q124095) |
Data type | String |
Template parameter | Wikipedia infobox parameters, if any; ex: "population" in en:template:infobox settlement |
Domain | types of items that may bear this property |
Allowed values | First alphabet is A-E (upper case); altogether are: Af, Am, Aw, BWh, BWk, BSh, BSk, Csa, Csb, Cwa, Cwb, Cwc, Cfa, Cfb, Cfc, Dsa, Dsb, Dsc, Dsd, Dwa, Dwb, Dwc, Dwd, Dfa, Dfb, Dfc, Dfd, ET, EF |
Example |
|
Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Source | Köppen climate classification |
Robot and gadget jobs | Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.) |
- Motivation
(Add your motivation for this property here.)
– ;Discussion Unbuttered Parsnip (talk) 12:07, 26 November 2015 (UTC)
- Support. Thryduulf (talk: local | en.wp | en.wikt) 15:39, 26 November 2015 (UTC)
- Although thinking about it more, perhaps using items (creating one for each climate classification) would be better? Thryduulf (talk: local | en.wp | en.wikt) 15:41, 26 November 2015 (UTC)
- Support in principle, BUT split into two properties "local climate" with a location domain and a "climate type" range, and a property "Köppen climate ID with a domain "climate type" and a string range. author TomT0m / talk page 15:45, 26 November 2015 (UTC)
- Comment This is 1 of 2 open proposals for Köppen climate classification: /Place, /Natural science. Mrwojo (talk) 15:40, 27 November 2015 (UTC)
Not done Duplicate of an earlier proposal. @Unbuttered Parsnip, Thryduulf, TomT0m: please comment at Wikidata:Property proposal/Place#climate 2 Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:05, 27 November 2015 (UTC)
Spacecraft code
Description | Code for this spacecraft (qualifiers) |
---|---|
Data type | String |
Example | Apollo 8 (Q184201) -> spacecraft -> Apollo Command/Service Module -> Spacecraft code (qualifiers) -> 103 Soyuz TMA-15M (Q610681) -> spacecraft -> Sojuz-TMA -> Spacecraft code (qualifiers) -> 11F732A47 No.715 |
Source | Nasa web site, other |
Proposed by | --Adert (talk) 12:24, 6 May 2015 (UTC) |
- Discussion
The spacecraft for Apollo 8 (Q184201) (for example) should not be "Apollo Command/Service Module", but an item for the specific instance of that craft. The code should then be a property of that item. Someone at Wikidata:Project chat will probably tell you where to get help making the relevant queries. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 6 May 2015 (UTC)
- I do not know ... In this case we have an item for any spacecraft that has flown in space ... I'm not sure it's a good idea --Adert (talk) 16:47, 6 May 2015 (UTC)
- No, we have an item for any craft that has flown a notable mission. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:01, 6 May 2015 (UTC)
- It is not a question of how many spacecraft we do or do not have items for, it is a question of whether or not this is an appropriate property to have for the items we do have or will have. Josh Baumgartner (talk) 04:28, 23 September 2015 (UTC)
- Oppose This should not be a generic property, but instead specific to the authority responsible for maintaining the code system. If the code is assigned by NASA, then we should have a property "NASA spacecraft code" or whatever they officially call their system. Likewise for other authorities. This way formatters and constraints can be tailored to the particular system the property represents. This is consistent with other authority control properties. Josh Baumgartner (talk) 04:28, 23 September 2015 (UTC)
- Oppose per Josh --Pasleim (talk) 12:32, 30 November 2015 (UTC)
Not done no support. ArthurPSmith (talk) 21:45, 2 December 2015 (UTC)
Eclipse properties
Various properties required for storing data related to lunar eclipses. Some of these might be relevant to other celestial events.
Gamma of eclipse
Description | MISSING |
---|---|
Represents | gamma (Q827951) |
Data type | Number (not available yet) |
Domain | lunar eclipses |
Allowed values | a decimal number between approximately -1.5 and +1.5, specified to 3 decimal places |
Example | ????? -> -1.057 |
Source | Wikipedia list article, e.g. en:List of 21st-century lunar eclipses |
- Please provide a description, and the item to which the example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:10, 14 July 2015 (UTC)
Not done Incomplete proposal; no support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:59, 27 November 2015 (UTC)
Magnitude of eclipse
Description | MISSING |
---|---|
Represents | magnitude of eclipse (Q1268559) |
Data type | Number (not available yet) |
Domain | lunar eclipses |
Allowed values | a decimal number between approximately -3 and +3, specified to 3 decimal places |
Example | -1.057 |
Source | Wikipedia list article, e.g. en:List of 21st-century lunar eclipses |
- Please provide a description, and the item to which the example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 14 July 2015 (UTC)
Not done Incomplete proposal; no support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 27 November 2015 (UTC)
conversion to SI base unit
Description | conversion into to the SI base unit (Q223662) |
---|---|
Data type | Number (not available yet) |
Domain | items for units |
Allowed values | number with SI base units |
Example | millimetre (Q174789) → 0.001 metre (Q11573), inch (Q218593) → 0.0254 metre (Q11573) |
- Support This in addition or independently of the property proposed above for "conversion into standard unit". --- Jura 09:39, 6 October 2015 (UTC)
- Comment Have we considered a generic "is equivalent to" property that would allow as many conversions as deemed fit? Or are people concerned with that getting out of hand? James Hare (NIOSH) (talk) 13:18, 7 October 2015 (UTC)
- Various things have been discussed here and there, it's just that it hasn't gotten to the creation of new property. We could simply use the property "numeric value" for any conversion. The idea of this new property is to do SI conversion calculations when possible. We might need another property if there is a rounding issue involved converting between two non-SI units or if there are some units that can't be converted (reliably) into SI units. --- Jura 14:09, 7 October 2015 (UTC)
- Comment Maybe we can try to start using the above proposed property, and see if there really is something missing? I am not sure about that, but not sure enough to stall this proposal with an
{{Oppose}}
-vote. -- Innocent bystander (talk) 07:34, 8 October 2015 (UTC) - Support. We need a generic "is equivalent to" (or "size") property but we also need a very specific property converting every measurement unit to SI units. This will be needed to create tools to compare measurements in various units with each other. The tools will need to go straight to this one single value property to get the info they need. If there are three different inches then they need three different items each with one claim using this property or, at worst various historic values and one current, preferred value. Joe Filceolaire (talk) 18:42, 19 October 2015 (UTC)
- I've moved this up next to the related proposal. I'm not sure this separate property is really needed, but as a sub-property of the generic conversion property it may be worthwhile. Josh Baumgartner (talk) 18:59, 27 October 2015 (UTC)
prison time served
Description | portion of prison sentence served |
---|---|
Data type | Number (not available yet) |
Template parameter | ? |
Domain | people sentenced to prison property:"judicial sentence" (proposed above) → imprisonment (Q841236) or life imprisonment (Q68676) |
Allowed values | number with unit day (Q573), week (Q23387), month (Q5151) or year (Q577) |
Example | Günter Schabowski (Q57445) → 1 year (Q577) |
Source | external reference, Wikipedia list article, etc. |
- Motivation
This is important to record for prisoners, as most do not serve the full length of their sentence in prison (parole, death, conviction overturned) Thryduulf (talk: local | en.wp | en.wikt) 16:05, 1 November 2015 (UTC)
- Discussion
- Question - would it be better to qualified with start and end dates? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:03, 6 November 2015 (UTC)
- Something like significant event (P793) imprisonment (Q841236) with the qualifiers might work. Thryduulf (talk: local | en.wp | en.wikt) 00:59, 9 November 2015 (UTC)
- IMHO this is only necessary for felonies. People which served only a short sentence have a right of rehabilitation.--Kopiersperre (talk) 08:26, 13 November 2015 (UTC)
Not done - use significant event (P793), as above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:53, 20 November 2015 (UTC)
ranking
Description | A ranking withing any ordered list |
---|---|
Data type | Quantity |
Template parameter | "draft" in en:template:Infobox ice hockey player, "area_rank" (and similar) in en:template:Infobox country |
Domain | people and events, main domain would probably be sports |
Example | P. K. Subban (Q27535) was drafted by Montreal Canadiens (Q188143) <ranking> 43th overall; Stephen Kiprotich (Q1702) participated in athletics at the 2012 Summer Olympics – men's marathon (Q1798983) <ranking> 1st; Prince Joachim of Denmark (Q159101) is part of Line of succession to the Danish throne (Q1142246) <ranking> 6th |
Source | mostly sports statistics |
Proposed by | Circeus (talk) 17:55, 23 August 2013 (UTC) |
- Discussion
- Comment: Like start time (P580), this would be a property used almost solely as a qualifier, and would supersede some tennis ranking properties currently pending. It could easily encompass the "seat number" property offered up above for some academies too. Circeus (talk) 17:58, 23 August 2013 (UTC)
- Support --Nightwish62 (talk) 21:47, 1 September 2013 (UTC)
- It would work for academies and the Swedish parlament depending on how you translate it, but the seats are not a "ranking" comparable to the tennis-ranking. -- Lavallentalk(block) 06:04, 9 September 2013 (UTC)
- I disagree, just because the ranking is dynamic doesn't make it inapplicable. The issue would be more of what property these would be a qualifier ("highest rank achieved", admittedly, probably cannot be worked with this property)
- @Circeus, Nightwish62, Lavallen: Sorted from Wikidata:Property_proposal/Pending/1 for discussion.
- Oppose Use series ordinal (P1545), ranking (P1352), or draft pick number (P1836) instead:
- Josh Baumgartner (talk) 20:07, 18 November 2015 (UTC)
- @Joshbaumgartner: I don't think "part of" is appropriate in your last example. Please use a property more specific to sequences like part of the series (P179). author TomT0m / talk page 12:47, 21 November 2015 (UTC)
- Oppose per Josh Baumgartner Jheald (talk) 20:24, 18 November 2015 (UTC)
- Question for the same reason: series ordinal (P1545) is useful for most rankings, and there are the other two sports-specific properties. How does the proposed property differ from series ordinal (P1545) and ranking (P1352)? Runner1928 (talk) 21:16, 18 November 2015 (UTC)
- Why do we have both series ordinal (P1545) and ranking (P1352) indeed ? author TomT0m / talk page 12:49, 21 November 2015 (UTC)
- Well, ranking (P1352) is an actual direct property specifically for sports ranking; it has datatype Number. series ordinal (P1545) is a qualifier property with datatype string (b/c the number may include nondigit parts). Circeus (talk) 13:14, 22 November 2015 (UTC)
- Why do we have both series ordinal (P1545) and ranking (P1352) indeed ? author TomT0m / talk page 12:49, 21 November 2015 (UTC)
I should point out that none of the property mentioned by Josh existed when I originally proposed this. The property is now clearly superfluous and I am withdrawing the proposal accordingly. Circeus (talk) 13:14, 22 November 2015 (UTC)
album
Description | The album the single or song was released on |
---|---|
Represents | album (Q482994) |
Data type | Item |
Template parameter | "van Album" in nl:Sjabloon:Infobox single |
Domain | album (Q482994) |
Allowed values | Any item that is an musicalbum |
Example | Paint It Black (Q1046717) is on Aftermath (Q389281) |
Source | external reference, Wikipedia list article (either infobox or source) |
Proposed by | Mbch331 (talk) |
- Motivation
Many singles are also part of an album. There is currently no way of linking these two, but as can be seen on several articles about singles, infoboxes mention the album they are part of. Mbch331 (talk) 20:13, 15 July 2015 (UTC)
- Discussion
Support. The description sounds a bit weird to me though, the name of the album would be a string, not an item. How about something like "the album the single or song was released on"? - Nikki (talk) 21:53, 15 July 2015 (UTC)
- Thanks for the tip on the description. Altered it. Mbch331 (talk) 07:19, 16 July 2015 (UTC)
- Question why just not use part of (P361) ? We already know the subject is a single, that thé object is an album, si basically there is no need for this property. So I'd say Weak oppose. What need to be thinked is that singles may be different version of the song however. TomT0m (talk) 11:55, 16 July 2015 (UTC)
- "Part of" is not quite correct, a single usually contains B-sides which are usually not part of the album. A single can be "part of" a discography, "part of" a series, "part of" a box set, which all imply that the single itself is part of the target item, whereas the meaning here is more "the main song of this single is taken from the linked album". - Nikki (talk) 04:52, 17 July 2015 (UTC)
- Support--- Jura 07:00, 2 August 2015 (UTC)
- Oppose use part of (P361) --Succu (talk) 21:20, 7 August 2015 (UTC)
- I already explained above why I think part of (P361) isn't the same. - Nikki (talk) 21:45, 12 August 2015 (UTC)
- I agree with Nikki. Maybe the members of Wikiproject Music can give their opinion. Mbch331 (talk) 15:23, 23 August 2015 (UTC) WikiProject Music has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
- I already explained above why I think part of (P361) isn't the same. - Nikki (talk) 21:45, 12 August 2015 (UTC)
- Oppose I agree with Nikki that a 'single' (which can contain b-sides) is not part of an 'album' (which contains songs), but the particular rendition of a 'song' can be both part of a 'single' and an 'album', thus linking the 'single' to the 'album' via the 'song':
Not done - no consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:08, 17 November 2015 (UTC)
Article ID
Data type | String |
---|---|
Domain | article (Q191067) |
Allowed values | no clear pattern across journals, though mostly alphanumeric; rather consistent within a given journal or publisher |
Format and edit filter validation | perhaps on a per-journal basis |
Source | ideally, the article itself, sometimes the journal's table of contents |
Robot and gadget jobs | probably, on a per-journal basis |
- Motivation
As discussed here, the paper-age property page(s) (P304) does not necessarily make sense for articles in online journals. Many articles thus have a journal-specific article ID instead of (or sometimes in addition to) traditional page numbers. They predated DOIs and often form the basis for their article-specific parts but cannot be uniformly deduced from DOI (P356), nor do all journals that use them also have DOIs. I think the best way to handle this kind of information here on Wikidata is a dedicated property. Daniel Mietchen (talk) 04:29, 2 August 2015 (UTC)
- Discussion
- Support --Succu (talk) 05:54, 2 August 2015 (UTC)
- Question: Would this be better stored with a URL datatype? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 2 August 2015 (UTC)
- @Pigsonthewing: A URL datatype could make sense if all of these IDs were formatted uniformly, but they vary a lot between journals and also over time within a given journal, while the format of the ID strings themselves varies less across journals and is rather stable over time. --Daniel Mietchen (talk) 22:04, 2 August 2015 (UTC)
- Support. Should be used in references alongside a 'stated in' statement linking to the journal or in items about the paper alongside (or as qualifier to) a statement linking to the journal. Joe Filceolaire (talk) 22:47, 2 August 2015 (UTC)
- Question What's about the existing properties DOI (P356) with an extended definition? Snipre (talk) 09:43, 3 August 2015 (UTC)
- @Snipre: Not sure I understand what you mean. The concept of DOI is rather well-defined, and it comes with technical infrastructure to resolve individual identifiers belonging to the system, which we use in DOI (P356). Mixing this up with identifiers external to the system does not make sense to me. --Daniel Mietchen (talk) 03:41, 8 August 2015 (UTC)
- Perhaps worth mentioning that there are yet other systems that overlap with the scope of DOIs, e.g. Publisher Item Identifier (Q4047616). --Daniel Mietchen (talk) 03:44, 8 August 2015 (UTC)
- Question Definition : there seems to be stuffs to clarify here. To be usable, is'nt is implicit that it's the ID ... in the original publication ? If it's to be used that way, I think it's better to use as a qualifier of the published in (P1433) statement. A hint it's to be used that way : the article may be published in several journal, in that case the id only make sense associated to the journal it is publicated into. Another one : the meaning and type of ID may depend of the journal, think for example of a formatter URL. This would be best into the journal item for this property to stay generic ... author TomT0m / talk page 10:06, 3 August 2015 (UTC)
- You have to cite doi:10.1371/journal.pcbi.1002727 like this: „Nussinov R (2012) A Future Vision for PLOS Computational Biology. PLoS Comput Biol 8(10): e1002727. doi:10.1371/journal.pcbi.1002727“. So this is very similar to a page. --Succu (talk) 10:58, 3 August 2015 (UTC)
- Yes, the ID is specific to a particular publication. For instance, the ID "e1000007" exists in PLOS Genetics, PLOS Biology, PLOS Medicine, --Daniel Mietchen (talk) 03:41, 8 August 2015 (UTC)
- Support I agree with Daniel's arguments above. Lawsonstu (talk) 08:19, 17 September 2015 (UTC)
@Daniel Mietchen, Succu, Snipre, TomT0m, Lawsonstu, Filceolaire: Done article ID (P2322) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:03, 17 November 2015 (UTC)
item number/enumerator
Description | item number |
---|---|
Data type | String |
Template parameter | None yet AFAIK. |
Domain | as qualifier for a work |
Allowed values | typically numbers |
Example | Nu falmer skoven trindt om land (Q12329345) published in (P1433) Den Danske Salmebog, 2003 edition (Q12308040) → "729" [1] |
- Motivation
Some works such as songs are included in larger works, such as song books. The works may have identifiers within the work, such as consecutive numbers. There is a range of other properties that record similar concept but none that seems to be suitable for creative works. Other properties are inventory number (P217) and house number (P670) Finn Årup Nielsen (fnielsen) (talk) 16:44, 17 September 2015 (UTC)
- Discussion
- Support This is logical and useful. Josh Baumgartner (talk) 20:58, 17 September 2015 (UTC)
- Sorry, this should not be listed under "Organization", but "Creative works". It should probably be moved. — Finn Årup Nielsen (fnielsen) (talk) 12:57, 18 September 2015 (UTC)
- Comment Magnus Manske just made me aware of series ordinal (P1545). I think this will in many cases do the work. The only catch is the \d+ format. In a few case one see, e.g., "1, 2, 3, 4, 5a, 5b, 6, 7", but it is a question whether this cannot be handled with just "1, 2, 3, 4, 5, 5, 6, 7". I am perhaps in favor of removing my proposal. — Finn Årup Nielsen (fnielsen) (talk) 12:57, 18 September 2015 (UTC)
- Oppose use series ordinal (P1545). The constraint on series ordinal (P1545) can be changed to allow 5a, 5b. --Pasleim (talk) 20:08, 4 October 2015 (UTC)
- The constraint there doesn't actually work. ;) --- Jura 20:17, 4 October 2015 (UTC)
- Comment I have now run into catalog code (P528) which may also be a possibility together with catalog (P972). — Finn Årup Nielsen (fnielsen) (talk) 10:04, 26 October 2015 (UTC)
- Oppose per Pasleim. Joe Filceolaire (talk) 09:45, 8 November 2015 (UTC)
Not done - suitable properties already exist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:33, 17 November 2015 (UTC)
replied at
Description | intellectual work that directly have reactions on new works |
---|---|
Data type | Item |
Domain | instance of (P31) : intellectual work (Q15621286) or its subclasses |
Allowed values | instance of (P31) : intellectual work (Q15621286) or its subclasses |
Example |
|
- Motivation
Many creative works are written in reply to previous ones. My examples refers to fiction/lyrics works, but it's concept is easily expandable to any human intellectual work. Current related properties (based on (P144), main subject (P921), inspired by (P941) and follows (P155)↔followed by (P156)) neither stores this information in complete way, neither allow any interested research to find things. This property should be completed by an reverse property, explained in next section. Lugusto (talk) 18:37, 31 October 2015 (UTC)
- Discussion
- I'm afraid I lean against this. Instead we should just have the "replies to" property since the 'being a reply to' thing is always a property of the newer second article. The first article is not written to be responded to. Joe Filceolaire (talk) 09:59, 8 November 2015 (UTC)
Not done No support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 22 November 2015 (UTC)
production code
Template parameter |
|
---|---|
Domain | episodes of a tv program |
- Motivation
With this property I can add this information to the infoboxes from Wikidata and it is used in more than one Wikipedia. I looked for properties that can be used to store that value but couldn't found any. -- Agabi10 (talk) 19:50, 31 October 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 10:00, 8 November 2015 (UTC)
- Support. Thryduulf (talk: local | en.wp | en.wikt) 13:40, 9 November 2015 (UTC)
@Agabi10, Filceolaire, Thryduulf: Done production code (P2364). Presumably, this should be used with, or as, a qualifier of the issuing production company? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 27 November 2015 (UTC)
NMHH film rating
Template parameter | |korhatár= in hu:Sablon:Film infobox |
---|---|
Domain | film (Q11424) |
Allowed values | TBC: NMHH I. , NMHH II. , NMHH III. , NMHH IV. , NMHH V. , NMHH VI. |
Example | The Man from U.N.C.L.E. (Q14488725) → NMHH III. |
- Motivation
Widely used in Hungarian Wikipedia. See also FSK film rating (P1981) and MPA film rating (P1657). Máté (talk) 07:30, 16 November 2015 (UTC)
- Discussion
- Support. Joe Filceolaire (talk) 17:31, 26 November 2015 (UTC)
@Máté, Filceolaire: Done NMHH film rating (P2363) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 27 November 2015 (UTC)
Competitor number
Description | The current number of a player |
---|---|
Data type | Number (not available yet) |
Template parameter | en:template:Infobox football biography clubnumber |
Domain | person |
Allowed values | 0-1000 |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | External reference, Wikipedia list article |
Robot and gadget jobs | they should be allowed |
Proposed by | Xaris333 (talk) 01:26, 3 May 2013 (UTC) |
- Although admittedly a rare case, there have been historic cases of players being given the squad number 0. Thumperward (talk) 13:56, 3 May 2013 (UTC)
Oppose unless broadened to be usable for all sports players who are assigned numbers. The label should be something more broadly applicable, such as 'jersey number' or maybe even 'competitor number', and the allowed values should be expanded to allow for 00 or larger numbers that are used in some sports. Thus we can avoid having a property like this for every sport. Joshbaumgartner (talk) 09:44, 9 May 2013 (UTC)- I change it to competitor number. Xaris333 (talk) 17:09, 9 May 2013 (UTC)
Support with implemented changes. Joshbaumgartner (talk) 13:07, 12 May 2013 (UTC)
- I change it to competitor number. Xaris333 (talk) 17:09, 9 May 2013 (UTC)
- @Xaris333, Thumperward: Sorted from Wikidata:Property_proposal/Pending/1 for discussion.
- Oppose Seems sport number (P1618) was created while this one was in the pending pile. I don't think this is needed any more. Josh Baumgartner (talk) 19:53, 18 November 2015 (UTC)
Not done - use sport number (P1618). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:28, 23 November 2015 (UTC)
varietal
Description | type of wine made primarily from a single named grape, herb or fruit variety |
---|---|
Data type | Item |
Domain | Zinfandel (Q204433) (Zinfandel), Cabernet Sauvignon (Q207310) (Cabernet Sauvignon), Chardonnay (Q213332) (Chardonnay), Merlot (Q213338) (Merlot), apple (Q89) (apple), Pinot gris (Q778601) (Pinot gris), Sangiovese (Q509162) (Sangiovese), Tempranillo (Q519874) (Tempranillo), Pinot meunier (Q947208) (Pinot meunier), Pinot noir (Q223701) (Pinot noir) and many others from list of grape varieties (Q1357585) (List of grape varieties), etc. |
Allowed values | Q, Text |
Example | Zinfandel wine (Q17329207) -> Zinfandel (Q204433) |
Source | List of grape varieties, Varietal |
Proposed by | SarahStierch (talk) |
- Discussion
Varietals aren't "genres" and that is the closest thing I can find to what would fit for listing types of grapes, fruits, or herbs used to make wines, liquors, beers, ciders, etc. This is my first time requesting a property and I'm unsure on if I did it right, but, perhaps others interested can help improve this request. Thank you for your consideration. SarahStierch (talk) 17:18, 6 July 2014 (UTC)
- Comment: Sarah, could you give an example of how you see this property being used in a Wikidata statement? For something like Zinfandel (Q204433), we might be able to build a set of varietals with existing properties, e.g. "Zinfandel has use (P366) varietal". Other useful statements might be "Zinfandel instance of (P31) cultivar", "Zinfandel subclass of (P279) Vitis vinifera". That instance of and subclass of usage would be consistent with how Wikidata classifies cats and dogs, e.g. Chihuahua (Q653).
- Anyhow, food and drink is an interesting area for structured data. Let me know if the above makes sense or if you have other ideas about how to model things. Cheers, Emw (talk) 19:59, 6 July 2014 (UTC)
- Hi User:Emw! Hmmm.... I'm not really sure actually...I'm pretty open minded and didn't give that aspect much thought outside of wanting to be able to use "varietal" as a statement. I'm not too sure...I can see the cultivar and vitis vinifera probably working best as statements versus the first varietal - but, since Zinfandel is a varietal, and it's a type of vitis vinifera.....hmmmm.... I'm leaning towards your experience in this to guide me! SarahStierch (talk) 20:06, 6 July 2014 (UTC)
- Sarah, things like "Zinfandel" are tricky because they're polysemous. As you you say, Zinfandel is a type of wine and a type of grape. However, many statements for Zinfandel wine are false for Zinfandel grape, and vice versa. For example, Zinfandel wine is not susceptible to bunch rot and Zindandel grapes do not have an alcohol by volume range of 12-17%. The wine derives from the grape. I think these statements illustrate the need for two separate items for the two different senses of Zinfandel.
- This kind of polysemy exists elsewhere, e.g. with the concept "influenza". Influenza is formally a type of disease, but it is often also used to refer to a type of virus. Separating the two concepts into two Wikidata items -- influenza (Q2840) and Orthomyxoviridae (Q287246) -- allows us to be much more precise and expressive about each subject.
- Perhaps we could do the same here with Zinfandel wine and the Zinfandel grape it derives from. That is, we could reserve Zinfandel (Q204433) for the grape and create a new item Zinfandel wine (Qx) for the wine. What do you think? Emw (talk) 00:29, 7 July 2014 (UTC)
- User:Emw you are a genius! (But you probably knew that already). Making new items for wine is a GREAT idea. How do we make that happen. SarahStierch (talk) 01:59, 8 July 2014 (UTC)
- @SarahStierch: I have started Wikidata:Property_proposal/Natural_science#fruit, I think the first step would be to start creating items for the fruits and linking them with their plants.--Micru (talk) 12:33, 17 August 2014 (UTC)
- @Emw, SarahStierch, Micru: You are absolutely correct about the need for multiple items for Zinfandel (Q204433). It is all in one Wiki article, but Zinfandel wine and Zinfandel grapes are separate and distinct concepts, so if there is data that applies to one and not the other, then they certainly need a new item. It can even be appropriate to give the wine and grapes each their own new item, while retaining the original Zinfandel (Q204433) to cover the general concept of Zinfandel, inclusive of both the wine and grapes, that is discussed in the Wiki article. We currently have made from material (P186) (alias ingredient) that can link the wine item with the grape item. Josh Baumgartner (talk) 22:46, 30 October 2015 (UTC)
- User:Emw you are a genius! (But you probably knew that already). Making new items for wine is a GREAT idea. How do we make that happen. SarahStierch (talk) 01:59, 8 July 2014 (UTC)
- Hi User:Emw! Hmmm.... I'm not really sure actually...I'm pretty open minded and didn't give that aspect much thought outside of wanting to be able to use "varietal" as a statement. I'm not too sure...I can see the cultivar and vitis vinifera probably working best as statements versus the first varietal - but, since Zinfandel is a varietal, and it's a type of vitis vinifera.....hmmmm.... I'm leaning towards your experience in this to guide me! SarahStierch (talk) 20:06, 6 July 2014 (UTC)
- Oppose use instance of (P31) or subclass of (P279) --Pasleim (talk) 16:25, 25 August 2015 (UTC)
- Oppose and recommend made from material (P186) instead. Josh Baumgartner (talk) 22:46, 30 October 2015 (UTC)
@SarahStierch: Not done This is a valid use-case, but we already have made from material (P186). I also note that, on Zinfandel wine (Q17329207), we already have natural product of taxon (P1582) -> Zinfandel (Q204433). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:51, 23 November 2015 (UTC)