Wikidata:Property proposal/Wikipedia infobox field

From Wikidata
Jump to navigation Jump to search

Wikipedia infobox field[edit]

Originally proposed at Wikidata:Property proposal/Sister projects

   Not done
Descriptionname of a field in the infobox of the Wikipedia in the same language, e.g. use English for a field on English Wikipedia.
Data typeMonolingual text
Domaingenerally Wikimedia infobox template (Q19887878), maybe some other Wikimedia template (Q11266439)
Example 1Template:Infobox film (Q6171351) → "film name"@en
Example 2Template:Infobox film (Q6171351) → "director"@en
Example 3Template:Infobox film (Q6171351) → "producer"@en
Example 4Template:Infobox film (Q6171351) → "attori"@it
Example 5Template:Infobox film (Q6171351) → "truccatore"@it
Example 6Template: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)[reply]

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)[reply]
    • 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)[reply]
      • 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)[reply]
        • @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)[reply]
          • "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)[reply]
  •  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)[reply]
(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)[reply]
  1. 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
  1. «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)[reply]
@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)[reply]
@Airon90: does this answer your concerns? --- Jura 06:57, 19 September 2020 (UTC)[reply]
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)[reply]
  • @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)[reply]
    • 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)[reply]
supported metadata (P8203)
Normal rank honorific (Q1326966) edit
<LOCALE_SPECIFIC_KEY> honorific_prefix (en)
honorífico (es)
0 references
add reference
Normal rank name (Q82799) edit
<LOCALE_SPECIFIC_KEY> native_name (en)
nombre_nativo (es)
0 references
add reference
Normal rank position (Q4164871) edit
<LOCALE_SPECIFIC_KEY> office (en)
oficina (es)
0 references
add reference
Normal rank position (Q4164871) edit
applies to part (P518) start time (Q24575110)
<LOCALE_SPECIFIC_KEY> term_start (en)
período_inicio (es)
0 references
add reference


add value
  •  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)[reply]
    • @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)[reply]
      • @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)[reply]
      • @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)[reply]
      • @Tinker Bell: would you consider support the proposal in its present form? --- Jura 10:56, 21 November 2020 (UTC)[reply]
        • @Jura1: Yes, I'll  Support it. --Tinker Bell ★ ♥ 23:53, 21 November 2020 (UTC)[reply]
        • 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)[reply]
          • 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)[reply]
  •  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)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Wikipedia_infobox_field&oldid=1462821277"