Wikidata

Wikidata:Property proposal/Wikipedia glossary entry

< Wikidata:Property proposal

Wikipedia glossary entry

edit

Originally proposed at Wikidata:Property proposal/Generic

Descriptiondescription of a concept in a glossary at Wikipedia
Data typeURL
Allowed valuesanchor of glossary pages
Example
Some samples from w:Glossary_of_cue_sports_terms
SourceWikipedias
Planned useCreate items for entries in w:Glossary_of_cue_sports_terms.
This could be expanded to the some 40 w:Category:Glossaries_of_sports. If each has 50 entries that qualify for inclusion in Wikidata: 2000 entries.
See alsodescribed at URL (P973)

Motivation

Sitelinks aren't possible. (Add your motivation for this property here.)
--- Jura 06:40, 30 March 2018 (UTC)[reply]

Possible alternatives (added after discussion with Marsupium below):

Alternatives aspects
sitelinks to redirects these are currently not available and it's likely that these wont happen ever. It's unclear how these would allow to check if all entries of a glossary are covered. Setting them up would require Wikidata editors to participate and/or re-organize Wikipedia editions in various languages. This is neither practical nor desirable.
sitelinks these are not possible, as a glossary can be linked just once. w:Glossary_of_cue_sports_terms in the samples above is already linked on glossary of cue sports terms (Q764884).
described at URL (P973) this was defined as a property when no specific property is available. Given the number of potential uses of this property and the similarities across glossaries entries, it seems preferable to create a dedicated property. This allows users and contributors to identify available glossary entries more easily. Users would also not be including all these Wikipedia links by default in their retrieval.
URL (P2699) general property for this datatype. Could work, but might need a qualifier to identify the type of resource
lexeme#senses wont include definitions (these would be written at Wiktionary), imports from Wikipedia or Wiktionary are not possible
items property would merely reflect glossary structure (which isn't the primary interest of this property), not the definitions. described by source (P1343) could do this.

Discussion

@Jura1:
  1. With "workaround" I meant 1) making the target page a non-redirect, 2) adding it as a sitelink, 3) making it a redirect (again).
  2. Which other ones are there? Perhaps I'd had opposed their creation? Depends on the specific case. How shall this property be used? How many use cases will there be? Perhaps you could provide more fields of the proposal template :)
  3. On the other hand there are easy ways to filter out Wikipedia links out of described at URL (P973). What kind of maintenance will have to be done?
--Marsupium (talk) 00:21, 4 April 2018 (UTC)[reply]
@Marsupium:. Thanks for your constructive input. I expanded the introduction above. (1) I added an explanation there why I think the workaround (or feature) isn't practical. (2) any of [1] given the explanation given on the creation of P973. (3) Maintenance would essential be attempting to identify entries that still need coverage. Depending on the use, people might not want Wikipedia sitelinks. These are generally handled separately, but it's clear that filtering could be done in one way or the other. Given the number of uses of P973 and the needed string manipulation, this might eventually become impractical. A union between this property and other(s) would still be possible.
--- Jura 07:31, 4 April 2018 (UTC)[reply]
@Jura1: Thank you for your clarifications. For 2000 cases it is perhaps reasonable to have such a property! --Marsupium (talk) 17:54, 5 April 2018 (UTC)[reply]
  • Weak   Support – as I don’t see a better option than the proposed one, which admittedly isn’t the most beautiful approach.
    User:Jura1 asked me to comment here at Topic:Uaovdg51q9l75wxy, as we are successfully collaborating in the field of tennis lately, and had some other interesting sports-related discussions as well. We found that it is really difficult to learn something about rather abstract concepts which are existing in practically all types of sport, since their Wikidata items have barely any claims and sitelinks. It would be great if we could expand our knowledge here, and the best would be to have quick access to a page where the concept is briefly described – as suggested in the proposal currently (URL datatype property, to be used with anchors on Wikipedia glossary pages). In my opinion the alternatives would be to wait for Lexemes (I am sceptical whether they will be useful at all for this particular problem), or to use described at URL (P973) as already mentioned by others. The latter however is typically used for external sources at URLs, and I would prefer to keep it like this in order to avoid trouble with users that complain about circular referencing schemes. —MisterSynergy (talk) 05:15, 25 April 2018 (UTC)[reply]
  • Weak   Oppose. Such items should have links to lexemes (wiktionary entries), not wikipedia pages. Additionally, do you want to link to all other languages (e.g. to ru:Словарь бильярдных терминов) also? --Infovarius (talk) 08:54, 25 April 2018 (UTC)[reply]
  •   Comment Lexemes might actually have worked for this, even though Wiktionary hasn't necessarily as many definitions for these as Wikipedia (any language), but it seems that the plan is to continue writing definitions at Wiktionary and not import any definitions into Wikidata. Anyways, thanks for taking the time to read the various discussions and providing productive input.
    --- Jura 10:40, 25 April 2018 (UTC)[reply]
  •   Comment Rather than URL datatype, a more stable (and language-independent?) property here seems like it would be to rename this property "described in Wikipedia glossary" or something like that, and have the value be the glossary item. So draw (Q51117558) and jump draw (Q51357961) would have this property with value glossary of cue sports terms (Q764884). That would also make it easy to get a list via SPARQL, etc. ArthurPSmith (talk) 17:01, 25 April 2018 (UTC)[reply]
@MisterSynergy: particularly interested in your view on the above. ArthurPSmith (talk) 17:04, 25 April 2018 (UTC)[reply]
Sure. The main motivation of Jura's proposal was not to provide a handle that helps us to generate our own glossaries from Wikidata items via SPARQL. For that purpose, your alternate suggestion would indeed be preferable, although other approaches without a separate property (e.g. “instance of: cue sports term”) would be possible as well.
What we need is something akin to sitelinks: link to a location where a (short) definition/description of the concept is provided, without the limitations of sitelinks (which are one per project, one per article). Wikipedia glossaries in the field of sports have lots of valuable information, but right now it is difficult to link it from existing items. The current situation also makes it difficult to create items for concepts which are described in a glossary, but not by a separate article anywhere. —MisterSynergy (talk) 18:20, 25 April 2018 (UTC)[reply]
Isn't the Wikidata description field sufficient for a (short) definition/description of the concept? ArthurPSmith (talk) 00:37, 27 April 2018 (UTC)[reply]
  • @Infovarius, Marsupium: given the commments above, would like to add something to this discussion. Otherwise, I will probably have to comment up with another approach.
    --- Jura 12:37, 27 April 2018 (UTC)[reply]
  •   Support I think this is the best solution to make items like the ones given as examples more useful. The only point I see is that "glossary" may not be well defined and there is difficulty in finding constraints to limit to the intended values? --Lymantria (talk) 11:53, 29 April 2018 (UTC)[reply]
  •   Oppose For several reasons: 1) on most cases it can be written on the item description or in the future lexeme-senses; 2) not all the glossaries have anchors; 3) each language requires a different url. If the intention is to query which terms belong to a certain glossary, then it would be better to have a property with data type item and label "described in glossary".--Micru (talk) 14:50, 30 April 2018 (UTC)[reply]
    • I think we addressed (1): Help:Description doesn't support that nor the plans for lexeme-senses, unfortunately. Imports from Wikipedia aren't possible. It's a mistaken assumption we have been several to make, including myself.
      I don't see how (2) and (3) are relevant: if there is no anchor, one wont be using it or has to add them first. URL datatype is flexible enough.
      --- Jura 15:00, 30 April 2018 (UTC)[reply]
  •   Comment are there other issues that need addressing?
    --- Jura 14:57, 30 April 2018 (UTC)[reply]
  •   Options @Infovarius: I summarized the additional alternatives above as well. If there are elements about senses I'm not aware of, you might want to add them. Otherwise, I would be glad if you could help formulate a working solution for this use case.
    --- Jura 10:13, 4 May 2018 (UTC)[reply]

Question: The example was draw (Q51117558) → https://en.wikipedia.org/wiki/Glossary_of_cue_sports_terms#draw. But why to use draw (Q51117558) and not tie (Q1164849)? Are they the same? And the second one has Wikipedia articles so someone can go to these article by these links. I mean that the different technical aspects of practicing a sport may already have items in Wikidata with links to Wikipedia articles. Xaris333 (talk) 16:38, 15 May 2018 (UTC)[reply]

  • @Xaris333: Thanks for your question. Maybe it allows to explain it better. The two concepts you mention just happen to have a name in common in English ("draw", not "tie" or "backspin", both aliases on these items), otherwise they are different. Q490309 is closer, but if you want to make statements about it in billiard, it would be better make it on a separate item. BTW, the enwiki sitelink there (w:backspin) doesn't mention cue sports. Obviously, if there is an existing item, no new item should be created.
    --- Jura 17:02, 15 May 2018 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Wikipedia_glossary_entry&oldid=682076328"