Wikidata:Property proposal/Wikipedia infobox field
Jump to navigation
Jump to search
Wikipedia infobox field
[edit]Originally proposed at Wikidata:Property proposal/Sister projects
Not done
Description | name of a field in the infobox of the Wikipedia in the same language, e.g. use English for a field on English Wikipedia. |
---|---|
Data type | Monolingual text |
Domain | generally Wikimedia infobox template (Q19887878), maybe some other Wikimedia template (Q11266439) |
Example 1 | Template:Infobox film (Q6171351) → "film name"@en |
Example 2 | Template:Infobox film (Q6171351) → "director"@en |
Example 3 | Template:Infobox film (Q6171351) → "producer"@en |
Example 4 | Template:Infobox film (Q6171351) → "attori"@it |
Example 5 | Template:Infobox film (Q6171351) → "truccatore"@it |
Example 6 | Template:Infobox film (Q6171351) → "cortometraggio"@it |
Planned use |
|
Motivation
[edit]Following a similar suggestion by @ElanHR: on project chat and describing_templates_and_their_fields. Allows to query infobox fields and map to properties. If there is interest, a similar property could be created for other projects (Add your motivation for this property here.) --- Jura 10:57, 29 January 2020 (UTC)
Discussion
[edit]Weak support I think the datatype should be "string" instead of "monolingual text". The parameter identifier actually doesn't have to match any language, and could be any alphabetical sequence. --Tinker Bell ★ ♥ 02:35, 2 February 2020 (UTC)Oppose per VIGNERON: this should be discussed. --Tinker Bell ★ ♥ 02:22, 17 September 2020 (UTC)- The idea is that the language matches the Wikipedia's. Otherwise, there is no way of knowing which WP this relates to. --- Jura 07:57, 3 February 2020 (UTC)
- Then oppose as we have no language code for 'simple', for the various Wikisources, nor Wiktionaries, for Wikispecies, for Commons, nor, indeed, for Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:59, 8 February 2020 (UTC)
- @Pigsonthewing: My understanding is that this property's scope is limited to Wikipedia (Wiktionaries, Wikispecies, etc. would use an equivalent property) and therefore the only ambiguity is between English Wikipedia and Simple Wikipedia. Fortunately (in my experience) templates from SimpleWiki tend to mirror those from EnWiki (e.g. Infobox:Person(en) and Infobox:Person(en)). Additionally I would not be too worried about this ambiguity as a problem only arise if one site used the same infobox key as another site but used it to represent different semantics. I have yet to see this case and I would imagine it occurs extremely infrequently. ElanHR (talk) 03:42, 21 February 2020 (UTC)
- "Wiktionaries, Wikispecies, etc. would use an equivalent property" That I also oppose. And it does not address the case of simple.Wikipedia. Your supposition about the mirroring of parameter names between that project and en.Wikipedia is overly optimistic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 21 February 2020 (UTC)
- @Pigsonthewing: My understanding is that this property's scope is limited to Wikipedia (Wiktionaries, Wikispecies, etc. would use an equivalent property) and therefore the only ambiguity is between English Wikipedia and Simple Wikipedia. Fortunately (in my experience) templates from SimpleWiki tend to mirror those from EnWiki (e.g. Infobox:Person(en) and Infobox:Person(en)). Additionally I would not be too worried about this ambiguity as a problem only arise if one site used the same infobox key as another site but used it to represent different semantics. I have yet to see this case and I would imagine it occurs extremely infrequently. ElanHR (talk) 03:42, 21 February 2020 (UTC)
- Then oppose as we have no language code for 'simple', for the various Wikisources, nor Wiktionaries, for Wikispecies, for Commons, nor, indeed, for Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:59, 8 February 2020 (UTC)
- The idea is that the language matches the Wikipedia's. Otherwise, there is no way of knowing which WP this relates to. --- Jura 07:57, 3 February 2020 (UTC)
- Comment I've been thinking about something similar, but I'm not sure this will work. Users will probably try to translate the entries, and not check what they actually are, users will not keep the entries updated, and the entries will diverge from actual entries in the templates. To keep the entries synchronized there must be some technical measure to do so, for example through TemplateData. A property should not be for an infobox, but for a template. That would also make it simpler to implement as part of the TD extension. Jeblad (talk) 15:58, 8 February 2020 (UTC)
- When doing Wikidata:WikiProject Movies/Tools#Wikipedia infobox mapping, I was worried about that too, but finally they proved quite stable. I think they are still used to do imports from Wikipedia. Obviously, depending on the use, some additional checks and re-sync needs to be done. I think the maintainers of TemplateData had declined to host a field for corresponding properties. --- Jura 16:13, 8 February 2020 (UTC)
- It is the same problem as maintaining sitelinks, they slowly disintegrate unless there are some way to automate the maintenance. (I wrote the original code for creating sitelinks, and the problem you try to solve is virtually the same.) Jeblad (talk) 16:54, 8 February 2020 (UTC)
- I think the granularity of the information, impact of changes, purpose and update pattern(s) are very different when compared to sitelinks. --- Jura 17:02, 8 February 2020 (UTC)
- @Jeblad: with TemplateData#API, we could check if the field list is current. Shall we move ahead with this proposal? --- Jura 10:59, 11 February 2020 (UTC)
- I believe this belongs in the server, not in the browser, and if you would put it in the browser, then you must enforce it in all clients. You would probably not be able to enforce use of it in the clients anyhow. Thatis in all language editions of Wikipedia. Jeblad (talk) 13:26, 12 February 2020 (UTC)
- @Jeblad: I think it depends on the purpose. To replace pages like the one of WikiProject Movies, it can easily live here. If a client wiki actually links an infobox to Wikidata, definitions could be moved there or more easily synced. As it hasn't happened in the last (decade), it might not happen soon though. --- Jura 17:07, 12 February 2020 (UTC)
- Sorry, but I'm pretty sure this will not work. Jeblad (talk) 21:23, 12 February 2020 (UTC)
- @Jeblad: Np. I know it works for the movies project. --- Jura 21:26, 12 February 2020 (UTC)
- We can't even get the communities to maintain TemplateData, which has a clear local effect, how should we enforce maintenance of an off-site value that has nearly no local effect? I don't see how that will happen. Jeblad (talk) 21:34, 12 February 2020 (UTC)
- Users regularly import data based on fields also listed on WikiProject Movies. Contrary to sitelinks, there is no point in adding all fields/all infoboxes if nothing is done with it here. --- Jura 21:41, 12 February 2020 (UTC)
- We can't even get the communities to maintain TemplateData, which has a clear local effect, how should we enforce maintenance of an off-site value that has nearly no local effect? I don't see how that will happen. Jeblad (talk) 21:34, 12 February 2020 (UTC)
- @Jeblad: I think it depends on the purpose. To replace pages like the one of WikiProject Movies, it can easily live here. If a client wiki actually links an infobox to Wikidata, definitions could be moved there or more easily synced. As it hasn't happened in the last (decade), it might not happen soon though. --- Jura 17:07, 12 February 2020 (UTC)
- I believe this belongs in the server, not in the browser, and if you would put it in the browser, then you must enforce it in all clients. You would probably not be able to enforce use of it in the clients anyhow. Thatis in all language editions of Wikipedia. Jeblad (talk) 13:26, 12 February 2020 (UTC)
- It is the same problem as maintaining sitelinks, they slowly disintegrate unless there are some way to automate the maintenance. (I wrote the original code for creating sitelinks, and the problem you try to solve is virtually the same.) Jeblad (talk) 16:54, 8 February 2020 (UTC)
- When doing Wikidata:WikiProject Movies/Tools#Wikipedia infobox mapping, I was worried about that too, but finally they proved quite stable. I think they are still used to do imports from Wikipedia. Obviously, depending on the use, some additional checks and re-sync needs to be done. I think the maintainers of TemplateData had declined to host a field for corresponding properties. --- Jura 16:13, 8 February 2020 (UTC)
- Weak support. Not only infoboxes need mapping between parameter names. Many other templates (and modules) need it, too. I have a vague recollection that Pigsonthewing tried to propose something similar once, although I might be wrong. The proper solution for this problem is Global templates. In the proposal I've written, I intentionally didn't specify how exactly will this be stored: maybe some kind of global TemplateData, maybe a different JSON structure, maybe something in Wikibase, and maybe something entirely different. However, this proposal here can be a step towards proper global templates. --Amir E. Aharoni {{🌎🌍🌏}} talk 18:20, 8 February 2020 (UTC)
- Support--Dispe (talk) 12:51, 1 May 2020 (UTC)
- Wait as, in the current state, this proposal need some serious rethinking and reworking. Why only infoboxes? why store this information in Wikidata? Not convinced at all so leaning to Oppose for now. Cheers, VIGNERON (talk) 11:18, 11 May 2020 (UTC)
- Yes, this need's to be property for any template parameters! Carn (talk) 11:45, 20 November 2020 (UTC)
- @Carn: could you provide a couple of usecases for non-infobox templates? If not, would you consider supporting the proposal in its present form? As mentioned below, we might add these later, but they might not have interesting fields to map. --- Jura 10:56, 21 November 2020 (UTC)
- en:Template:Cite web "title" = es:Plantilla:Cita web "título"
fr:Modèle:Références "groupe" = ru:Шаблон:Примечания "group" Carn (talk) 15:04, 4 December 2020 (UTC)- @Carn: Indeed, I suppose this type of template could be added as well with the proposed property, even with the current label. I wonder what happened with the WMF development that was planning to integrate Wikipedia citation templates directly with Wikidata. --- Jura 12:47, 5 December 2020 (UTC)
- en:Template:Cite web "title" = es:Plantilla:Cita web "título"
- @Carn: could you provide a couple of usecases for non-infobox templates? If not, would you consider supporting the proposal in its present form? As mentioned below, we might add these later, but they might not have interesting fields to map. --- Jura 10:56, 21 November 2020 (UTC)
- Yes, this need's to be property for any template parameters! Carn (talk) 11:45, 20 November 2020 (UTC)
- Comment seems we addressed most concerns. Oddly we still don't have an alternative. --- Jura 06:23, 30 August 2020 (UTC)
- Strong oppose No code for "simple", no way to map correctly every parameter for every infobox (e.g. "language" could be in some cases language of work or name (P407) or programmed in (P277)) because many templates use "simple" words as parameter because there is a unique meaning in the context. You cannot generalize that for every templates in every language. I suggest you to wait and to find another possible way as this is an important and useful task --★ → Airon 90 16:21, 3 September 2020 (UTC)
- @Airon90: Simple wiki would need a separate property if there is interest (frequently it's similar to enwiki though). The plan isn't to map every template in every language, but specific infoboxes linked from a given item, according to the field_names used there. Infoboxes can only have the same field_name once. The idea is to make it easier to gather fields that need to be mapped to Wikidata. --- Jura 16:33, 3 September 2020 (UTC)
- It doesn't have sense to me to have a separate property for just one wiki.
- On itwiki Template:Infobox officeholder (Q5830052) has fields "predecessore" and "successore" (replaces (P1365) and replaced by (P1366)) while Template:Infobox OS (Q5856866) has fields "predecessore" and "successore" (follows (P155) and followed by (P156)). How could you handle this situation? --★ → Airon 90 17:05, 3 September 2020 (UTC)
- @Airon90: Simple wiki would need a separate property if there is interest (frequently it's similar to enwiki though). The plan isn't to map every template in every language, but specific infoboxes linked from a given item, according to the field_names used there. Infoboxes can only have the same field_name once. The idea is to make it easier to gather fields that need to be mapped to Wikidata. --- Jura 16:33, 3 September 2020 (UTC)
- (1) if there is no interest for simplewiki, there wont be a separate property. Besides, I don't really see the advantage of a single property when it leads to having to add a qualifier to every statement instead (twice as many triples).
- (2) I added "predecessore"@it as samples. They can then be analyzed separately for each template. However, "predecessore" (and "successore") are probably the least interesting infobox fields, as they are fairly generic. The samples of Template:Infobox film (Q6171351) above are much more crucial, as it's unique to the infobox and it's the type of information that is useful to gather (I think) and map. @Airon90: --- Jura 17:23, 3 September 2020 (UTC)
- Please, explain why you don't see advantage(s) in using just one property instead of many. Contributors may not find some properties directly or may use the "main" one in a wrong way, causing errors or lack of information
- «They can then be analyzed separately for each template» how? You consider some simple cases, where the name of the parameter links directly to the property. This work will be useful if *every* parameter is correctly analyzed without struggling in finding the correct property. Moreover, some template *may* be implemented on Wikipedia using a wrong property (e.g. in some cases, values of P155 should be moved to P1365 and/or viceversa). On Wikidata you link a parameter to a property while on Wikipedia the value of that parameter is automatically scraped from another property.
- I think that this work is necessary and useful but this isn't the correct way to implement this work. --★ → Airon 90 19:39, 3 September 2020 (UTC)
- @Airon90: (1) It's clear that some contributors never find the correct property. The question here is not between one and many, but one and possibly a few others (but I haven't seen anybody interested yet). As said, it's easier to just use a property and a value than a property and value and a qualifier for each field. (2) The idea here is not to redo infoboxes of Wikipedia, the idea is merely to analyze its contents. Mappings can change and may need updating, but that shouldn't prevent one from doing mappings. This isn't much different from any other property (e.g. Wikidata:Property_proposal/booking_URL). Do you have any constructive suggestions for alternatives? (besides the one by ElanHR discussed earlier). --- Jura 19:52, 3 September 2020 (UTC)
- @Airon90: does this answer your concerns? --- Jura 06:57, 19 September 2020 (UTC)
- I think that this work is necessary and useful but this isn't the correct way to implement this work. --★ → Airon 90 19:39, 3 September 2020 (UTC)
- We would not map all of them, but we need and we can map the most important. Carn (talk) 11:46, 20 November 2020 (UTC)
- @Tinker Bell: can you clarify what aspects you think need to be discussed? The discussion is still open. I think the primary focus should be infobox templates as there have fields that could potentially be properties. I don't think the applies to (for example) navigational templates. These would just have 1= or 2=. Obviously, if there are others we find useful, we could add them later. Which ones did you have in mind? --- Jura 06:32, 19 September 2020 (UTC)
- This proposal is constrained to Wikipedia subprojects, but other non-Wikipedia projects also have infoboxes, like Wikisource. That's why we can't use monolingual string datatype for this property. I also think that having the same property repeated many times, one for each Wikimedia project is a nonsense.
- I would like having a way to document templates of any kind on Wikidata, and on that direction, I think the ElanHR's proposal you have linked is a good start. It has some problems too, but we could discuss them. --Tinker Bell ★ ♥ 09:06, 22 September 2020 (UTC)
- @Tinker Bell: Thanks for your feedback. The proposal is an attempt to improve over an aspect of ElanHR's draft, notably "LOCALE_SPECIFIC_KEY", that can't really work without an additional property that would indicate in which project it would be used. As "LOCALE_SPECIFIC_KEY" was meant as a qualifier, one couldn't add one anyways. Even if "LOCALE_SPECIFIC_KEY" was set out as a main statement (as "Wikipedia infobox field" proposed here), it would still need a qualifier on every statement to specify the project. I don't think that would be efficient. Aas we don't have "many" project families, it's easier to create an additional one when needed. Maybe you see a different way to improve over "LOCALE_SPECIFIC_KEY"? How would you do it? --- Jura 07:56, 23 September 2020 (UTC)
- @Jura1: I thought a lot in two possible solutions, but neither are easy of implement:
- A new datatype, similar to monolingual text, but using projects listed on the interwiki database, or any other source. This datatype could be useful for other future properties related to Wikimedia projects. An example for Template:Infobox officeholder (Q5830052):
- Template:Infobox officeholder (Q5830052)supported metadata (P8203)honorific (Q1326966)
<LOCALE_SPECIFIC_KEY>honorific_prefix (enwiki) - Template:Infobox officeholder (Q5830052)supported metadata (P8203)honorific (Q1326966)
<LOCALE_SPECIFIC_KEY>honorífico (eswiki)
- Template:Infobox officeholder (Q5830052)supported metadata (P8203)honorific (Q1326966)
- Splitting each template on its own item, and store documentation in each item. Although we would lost the interwiki feature, we could say that each template is actually a different implementation of the same infobox model, and this is something that we already do for the different community translations of an specific work in Wikisource. An example:
- <enwiki infobox>implementation of (P4428)Template:Infobox officeholder (Q5830052)
- <enwiki infobox>used by (P1535)English Wikipedia (Q328)
- <enwiki infobox>supported metadata (P8203)honorific (Q1326966)
<LOCALE_SPECIFIC_KEY>honorific_prefix - <eswiki infobox>implementation of (P4428)Template:Infobox officeholder (Q5830052)
- <enwiki infobox>used by (P1535)Spanish Wikipedia (Q8449)
- <eswiki infobox>supported metadata (P8203)honorific (Q1326966)
<LOCALE_SPECIFIC_KEY>honorífic
- A new datatype, similar to monolingual text, but using projects listed on the interwiki database, or any other source. This datatype could be useful for other future properties related to Wikimedia projects. An example for Template:Infobox officeholder (Q5830052):
- Maybe both solutions are too complicated, and maybe we could find another solution. While that happen, now I see your proposal as a good point to start, we always can improve the model later:
- @Jura1: I thought a lot in two possible solutions, but neither are easy of implement:
- @Tinker Bell: Thanks for your feedback. The proposal is an attempt to improve over an aspect of ElanHR's draft, notably "LOCALE_SPECIFIC_KEY", that can't really work without an additional property that would indicate in which project it would be used. As "LOCALE_SPECIFIC_KEY" was meant as a qualifier, one couldn't add one anyways. Even if "LOCALE_SPECIFIC_KEY" was set out as a main statement (as "Wikipedia infobox field" proposed here), it would still need a qualifier on every statement to specify the project. I don't think that would be efficient. Aas we don't have "many" project families, it's easier to create an additional one when needed. Maybe you see a different way to improve over "LOCALE_SPECIFIC_KEY"? How would you do it? --- Jura 07:56, 23 September 2020 (UTC)
supported metadata (P8203) |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
add value |
- I've replaced <PROPERTY_USED_BY_TEMPLATE> with supported metadata (P8203) and <QUALIFYING_PROPERTY> with applies to part (P518) because I thing they fit well: I didn't use a property datatype for <PROPERTY_USED_BY_TEMPLATE> because there are concepts that could be stored in a parameter that could not have a property in Wikidata, and every Wikidata property should be linked with a concept via Wikidata item of this property (P1629) and Wikidata property (P1687). What do you think? --Tinker Bell ★ ♥ 08:41, 4 October 2020 (UTC)
- Comment added another planned use. --- Jura 06:59, 19 September 2020 (UTC)
- Comment @Tinker Bell: thanks for your detailed feedback. I like the idea of using supported metadata (P8203) for this. While eventually we would create properties (if they are missing), this would allow to described them before they are created. Once available, merely adding P1687 will do. I think it's an improvement over using a property-datatype property. I hand't thought of that.
Given that many qualifiers are hard to handle on a single statement, I'd rather make P8203 a qualifier for the proposed property. What do you think? --- Jura 08:46, 5 October 2020 (UTC)- @Jura1: I think 'supported metadata' describes an aspect of the template, not of a parameter, so the principal property should be P8203. --Tinker Bell ★ ♥ 06:33, 15 October 2020 (UTC)
- @Tinker Bell: I suppose there are two ways of seeing it. If "supported metadata" is the main property, it needs a restrictive qualifier. If "infobox field" is the main property, it can do with a non-restrictive qualifier: that means that the field if present, always supports the metadata. My POV is that non-restrictive qualifiers are generally preferred.
The approach with using this as qualifier could lead to many qualifiers on the same value. I don't see that working on other properties. Do you? --- Jura 05:24, 16 October 2020 (UTC)- @Jura1: I think using "infobox field" as main property could make difficult modelling qualifiers, e.g. <item>supported metadata (P8203)position (Q4164871)
applies to part (P518)start time (Q24575110): we can't do <item><LOCALE_SPECIFIC_KEY>"term_start"@en supported metadata (P8203)position (Q4164871) applies to part (P518)start time (Q24575110) because P518 will lose its meaning here. I also think that a <LOCALE_SPECIFIC_KEY> property without a P8204 qualifier is as useless as a P8204 property without a <LOCALE_SPECIFIC_KEY> qualifier. --Tinker Bell ★ ♥ 08:20, 23 October 2020 (UTC) - I do not know what you are talking about, but this property should be TemplateData compatible (with aliases, data type: number/text, etc). Templates are already an items, then it's parametres could be listed either as properties of this item with some qualifiers, either (for popular parametres like "title" in cite templates which can be standartized through different languages wikis) as links to another items maybe? Carn (talk) 17:15, 4 December 2020 (UTC)
- @Jura1: I think using "infobox field" as main property could make difficult modelling qualifiers, e.g. <item>supported metadata (P8203)position (Q4164871)
- @Tinker Bell: Admittedly, this is a somewhat weak point of the approach, possibly of any approach. It's clear that it's hard to map the full details of the statement. The question is if it's really worth doing it to find that there is a start and end date for the position. If it's thought to be desirable, I suppose one could either create an item <start date of position> and use that as P8203 value or qualify <start date> in some way to indicate it applies to the position. Even in the sample you gave above, I think using <position> as metadata available for "term_start" isn't really optimal either. In any case, I think we are probably mostly interested in getting all infoboxes that have metadata about positions (whatever the level of detail). --- Jura 09:11, 31 October 2020 (UTC)
- @Tinker Bell: would you consider support the proposal in its present form? --- Jura 10:56, 21 November 2020 (UTC)
- @Jura1: Yes, I'll Support it. --Tinker Bell ★ ♥ 23:53, 21 November 2020 (UTC)
- I don't know the perfect way to do it yet. I would consider storing table data on commons. @Tinker Bell proposal is that each big template will have many supported metadata (P8203) properties. And we see links for concepts, that are stored in these parameters on the pages of wikis. I see the good use for this for templates translation. So in order to translate some parameters, we will need to get all the list of all parameters of this template in this language, then find ones in this many lists of parameter names we need to translate and substitute names from other languages if described. I imagine how it is possible to set by the bot from the template code (or module code) to find whether all parameter names are described in template data, or not). In fact, if some kind of solution for centralized storage of template data is supposed — this will duplicate them.
This raises the question of what is the subject of the corresponding item in general. If a template performs the same functions as other templates but has completely different, incompatible parameters — is this a different template? Perhaps the parameters can be a measure of the similarity of templates, and if different templates have very different parameters, then they are not the same entity at all. Carn (talk) 09:49, 6 December 2020 (UTC)- initially I was going to write about your suggestion for the inclusion of citation templates, that this may not be needed as WMF staff is already implementing a solution for these, but, after checking, it seems that the steps taken in 2019 didn't lead to a running solution (yet), so, if you are interested in checking these, why not. The citation thing might also have been on a wishlist some years back, but we still have to work with currently available tools and features. I agree with the point you made earlier: it's better to focus on some templates than try to map all of them. Once the data is struructured here, it can be reused and/or converted further. --- Jura 17:03, 6 December 2020 (UTC)
- @Tinker Bell: I suppose there are two ways of seeing it. If "supported metadata" is the main property, it needs a restrictive qualifier. If "infobox field" is the main property, it can do with a non-restrictive qualifier: that means that the field if present, always supports the metadata. My POV is that non-restrictive qualifiers are generally preferred.
- @Jura1: I think 'supported metadata' describes an aspect of the template, not of a parameter, so the principal property should be P8203. --Tinker Bell ★ ♥ 06:33, 15 October 2020 (UTC)
- Not done Unfortunately I see a lot of interest in this, but not sufficient consensus for a particular method of implementation. It might be worth getting the interested parties together to hammer out a more detailed proposal before returning here. — Martin (MSGJ · talk) 10:46, 19 July 2021 (UTC)