Wikidata:Property proposal/Pending
Awaiting multilingual text type edit
Sandbox-Multilingual texts (en) edit
Description | A sandbox type per available data type |
---|---|
Data type | Multilingual text (not available yet) |
Domain | any |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | GZWDer (talk) 09:37, 6 June 2013 (UTC) |
- Discussion
IUPAC name edit
Description | en:IUPAC name |
---|---|
Data type | Multilingual text (not available yet) |
Domain | chemistry |
Example | see Wikidata:Chemistry_task_force/Properties. |
Source | en:PubChem |
Proposed by | GZWDer (talk) 03:07, 7 June 2013 (UTC) |
- Discussion
- Support Snipre (talk) 21:41, 10 June 2013 (UTC)
- Support --Kaligula (talk) 07:06, 19 June 2013 (UTC)
- Hmm, this is for some compounds still a disputed property .. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
- There is always one IUAPC and most of the time you can put more than one. And as IUAPC is going to publish some rules to select the preferred name when several possibilities exist (see here, we can define one name for that property. Snipre (talk) 12:49, 26 June 2013 (UTC)
- I have noticed French language using alternative characters with accents for the names, which does not quite match use in English. So is the non accented use correct? Graeme Bartlett (talk) 08:15, 29 June 2013 (UTC)
- In French non accented names are not correct. That's why a multilingual property is proposed: each language will have its own name, so the value of this property will be a list of chemical names associated with a language. Snipre (talk) 08:32, 29 June 2013 (UTC)
- Support, though the domain should probably be refined to "chemical compounds". Otherwise perhaps I'll finally get to see the IUPAC name for titin! It would also help to have an example, if only for documentation. Proposing a canonical source for IUPAC name claims would be helpful, too. Emw (talk) 12:14, 29 June 2013 (UTC)
- Support - additionally it should be investigated if this can be filled in by a bot because it is pretty standardized. --Tobias1984 (talk) 14:51, 11 July 2013 (UTC)
- Support -- Andrew Su (talk) 23:10, 19 July 2013 (UTC)
- Support – IUPAC name property should be available. It's rather a unique identifier in a sense that a IUPAC name defines single compound. There can be more different IUPAC names for single compound (but it is the case for SMILES strings, maybe even "canonical" as well). For that type of uniqueness, the PIN (Preferred IUPAC Name, introduced in 2013) can be used (which however is still somewhat open problem, e.g. for natural compounds). —Mykhal (talk) 18:44, 29 March 2020 (UTC)
Description/review (en) edit
Description | voy:Template:Listing A brief description of the listing |
---|---|
Data type | Multilingual text (not available yet) |
Template parameter | content |
Domain | Items with Wikivoyage listings |
Allowed values | any text |
Example | Exploratorium (Q206518) -> A great kid friendly option, with lots of interactive exhibits teaching about science, with intriguing displays about the mind, natural systems, sound, sight, and much much more. |
Source | Wikivoyage listings |
Proposed by | Filceolaire (talk) 00:11, 19 August 2013 (UTC) |
- Discussion
- Support Support as nom. See this RFC. Filceolaire (talk) 00:11, 19 August 2013 (UTC)
- Support but why the name "personal"? Wikivoyage POI descriptions feel indeed more personal than Wikipedia sentences, but they are not the result of a single individual, they are most often the result of a wiki collaboration. Nicolas1981 (talk) 08:04, 28 November 2013 (UTC)
- Support -- DerFussi 11:27, 24 January 2014 (UTC)
- Support --NatiSythen (talk) 07:59, 28 January 2014 (UTC)
- Support As stated above multilingual support is necessary. --RolandUnger (talk) 13:10, 2 February 2014 (UTC)
Comment: @Filceolaire: Please provide an example and proper description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 22 November 2015 (UTC)- Renamed, description ammended, example added as comments by @Nicolas1981, Pigsonthewing:. Filceolaire (talk) 04:52, 24 November 2015 (UTC)
Awaiting time type with precision second edit
checkin time (en) edit
Description | Time of hotel reservation or airport flight check-in |
---|---|
Represents | check-in (Q1068755) |
Data type | Point in time |
Template parameter | voy:Template:Listing : "checkin" - Template:Listing (Q14330485) |
Domain | Hotel reservation or airport flight |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | GZWDer (talk) 10:39, 18 June 2013 (UTC) |
- Discussion
- Support. Property should be number with unit type hours. Needs a 'day' qualifier property to say which day the time given applies to (mon, weekdays, bank holidays, second tuesday in the month). Filceolaire (talk) 23:53, 18 August 2013 (UTC)
- Support as time duration in hours. Danrok (talk) 22:05, 30 August 2013 (UTC)
- Support Nicolas1981 (talk) 08:49, 29 January 2014 (UTC)
- Probably in some places it can be fractional (12.30) so not only hours. --Infovarius (talk) 05:18, 22 October 2014 (UTC)
checkout time (en) edit
Description | Time of hotel reservation check-out |
---|---|
Data type | Point in time |
Template parameter | voy:Template:Listing : "checkout" - Template:Listing (Q14330485) |
Domain | Hotel reservation |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | GZWDer (talk) 10:39, 18 June 2013 (UTC) |
- Discussion
- Support. See comments on checkin time. Filceolaire (talk) 23:55, 18 August 2013 (UTC)
- Support Nicolas1981 (talk) 08:50, 29 January 2014 (UTC)
Epoch edit
Description | epoch of the elements of the orbits of artificial satellites and astronomical objects |
---|---|
Represents | epoch (Q2703) |
Data type | Point in time |
Template parameter | en:Template:Infobox spaceflight: "orbit_epoch" (Template:Infobox spaceflight (Q14907524)); en:Template:Planetbox orbit: "epoch" (Template:Planetbox orbit (Q8116171)) |
Domain | astronomical objects, artificial satellites, spaceflight |
Example | Apollo 11 (Q43653) => July 19, 1969, 21:44 UTC; Gliese 876 d (Q869944) => 2,450,602.093 HJD (!!) |
Proposed by | Paperoastro (talk) |
- Discussion
Epoch is the seventh parameter of an orbit: it is necessary to define an orbit. In this proposal I'd like to discuss:
- we need a new property (this) or we can use point in time (P585)?
- epoch refers to 6 orbital parameters: how to join them?
- for spaceflights and artificial satellites the epoch is expressed in usual calendar unity; for extrasolar planet in Julian day or some its variants. How to solve it?
Paperoastro (talk) 12:32, 25 October 2013 (UTC)
- Support It might be useful to have a specific property because it can be further developed to have customisations and different representations (J2000, TT, etc.). As for bundling orbit parameters, one possible solution is to have an item to represent the orbit and link it with a property "orbit parameters". --Micru (talk) 20:37, 12 November 2013 (UTC)
- I am not an astronomer and having read the en:Epoch (astronomy) article I am still confused.
- On the one hand epoch refers in some way to unusual ways for expressing calendar dates - for these we could use the current wikidata time variable type and ask the devs to offer alternative ways of displaying this at some future date
- on the other hand it seems to refer to unusual units of time (Julian years and Julian days) - for these we can use seconds until the devs get round to creating alternative units of time
- on the third hand it refers to IAU standards - we can create items for these
- What have I misunderstood? Filceolaire (talk) 13:28, 3 June 2014 (UTC)
Contact times of eclipses edit
Description | Contact times of eclipses: P1, U1, U2, U3, U4, P4 |
---|---|
Data type | Point in time |
Domain | lunar and solar eclipses |
Allowed values | time in UTC |
Example | 6 April 2015, 03:22 UTC. qualifier <applies to part:U4 - solar eclipse> |
Source | Wikipedia list article, e.g. en:List of 21st-century lunar eclipses |
- I have amended the example as I understand it should be used. Please check I got it right.
- Can this property be extended so it can be used on solar eclipses as well? Creating a property that can only be used on lunar eclipses seems a bit narrow. Filceolaire (talk) 00:10, 29 April 2015 (UTC)
- Yes, I believe this is correct (see en:Solar eclipse of August 11, 1999#Notable times and coordinates for example. I will ask someone more knowledgeable to comment here. MSGJ (talk) 09:52, 29 April 2015 (UTC)
- P1-4 and U1-4 apply to solar and lunar eclipses, but differently. A solar eclipse is a en:Transit (astronomy) so the timing is based on the viewing location INSIDE a shadow, while a lunar eclipse has viewers looking at an object INSIDE a shadow, so everyone sees the same appearance at the same universal time. So knowing the P1-4,U1-4 times for a solar eclipse are less useful for any given observer. Tomruen (talk) 01:08, 30 April 2015 (UTC)
- If U4 for a solar eclipse is different from U4 for a lunar eclipse then we should have separate items for these with the "applies to part" qualifier linking to the appropriate item in each case. This means this property could be used for solar eclipses if we just change the label. I would Support this property if you made this change to the property label and description. Filceolaire (talk) 03:04, 30 April 2015 (UTC)
- Could you explain what you mean by "This means this property could be used for solar eclipses if we just change the label." Does that mean that properties can have more than one label? Or do you mean that you could have two statements for "subject item of this property"? Or do you mean something else? MSGJ (talk) 12:24, 30 April 2015 (UTC)
- Rename the property as "Contact time for eclipses". Change the description to "Contact time for lunar and solar eclipses (U1, U2 etc. lunar and U1, U2 etc. solar)". Filceolaire (talk) 16:41, 30 April 2015 (UTC)
- Done, although no corresponding items created yet MSGJ (talk) 09:22, 5 June 2015 (UTC)
- I ammended the example a little. I think this is good now and support - as my comment above. Joe Filceolaire (talk) 16:48, 12 September 2015 (UTC)
- Done, although no corresponding items created yet MSGJ (talk) 09:22, 5 June 2015 (UTC)
- Rename the property as "Contact time for eclipses". Change the description to "Contact time for lunar and solar eclipses (U1, U2 etc. lunar and U1, U2 etc. solar)". Filceolaire (talk) 16:41, 30 April 2015 (UTC)
- Could you explain what you mean by "This means this property could be used for solar eclipses if we just change the label." Does that mean that properties can have more than one label? Or do you mean that you could have two statements for "subject item of this property"? Or do you mean something else? MSGJ (talk) 12:24, 30 April 2015 (UTC)
- If U4 for a solar eclipse is different from U4 for a lunar eclipse then we should have separate items for these with the "applies to part" qualifier linking to the appropriate item in each case. This means this property could be used for solar eclipses if we just change the label. I would Support this property if you made this change to the property label and description. Filceolaire (talk) 03:04, 30 April 2015 (UTC)
- Comment Created as Property:P2569, but later deleted, as times couldn't be set even by api. See also Topic:Szp5r8e8djzsy873.
--- Jura 07:56, 24 March 2016 (UTC)
Awaiting Shape Expression datatype edit
Shape Expression for class edit
Originally proposed at Wikidata:Property proposal/Generic
Description | Shape Expression that members of a class should conform to |
---|---|
Represents | Shape Expressions (Q29377880) |
Data type | ⧼datatypes-type-EntitySchema⧽ (not available yet) |
Domain | class |
Example 1 | human (Q5) → E10 |
Example 2 | film festival (Q220505) → E11 |
Example 3 | film festival edition (Q27787439) → E12 |
Example 4 | natural number (Q21199) → E13 |
Motivation edit
Property to link a class to the Shape Expression that members of it should conform to.
This will make it easier to query for Shape Expressions that exist, and quickly see what has been defined for a particular class. Jheald (talk) 16:56, 28 May 2019 (UTC)
- Note: Implementation will require EntitySchema to be added to the set of data-types that can be values for Wikidata statements. There is a ticket for this on Phabricator, which Léa hopes should be resolved in the coming weeks.[1]. Jheald (talk) 07:54, 29 May 2019 (UTC)
Discussion edit
- Proposed. Jheald (talk) 16:56, 28 May 2019 (UTC)
- Support - PKM (talk) 18:34, 28 May 2019 (UTC)
- Support —MisterSynergy (talk) 18:43, 28 May 2019 (UTC)
- Support Dhx1 (talk) 18:44, 28 May 2019 (UTC)
- Support Finn Årup Nielsen (fnielsen) (talk) 18:52, 28 May 2019 (UTC)
- Oppose This proposal needs to say much more about how it is supposed to work. Example 1 shows some of the problems. What does "member" mean here? Are only items that are an instance of (P31) to human (Q5) supposed to be covered, or are instances of subclasses (transistive-reflexive closure of subclass of (P279)) also covered? Then there are problems with the shape expression E11 as a shape for humans. The shape requires that the only instance of link for humans goes to human (Q5). The example shape needs to show at least some interesting conditions, such as requiring that children of humans are humans. Example 4 shows more problems. What items are covered here at all? Presumably natural numbers are not items at all, which means that they don't have any outgoing RDF triples. Even if they did, natural numbers should not be instances of instances of natural number. Peter F. Patel-Schneider (talk) 19:46, 28 May 2019 (UTC)
- Comments:
- Interestingness: "The example shape needs to show at least some interesting conditions, such as requiring that children of humans are humans" Yes absolutely, but note that ShEx are only a couple of hours old. I think we will gradually expand it these coming days.
- Members: I do not think this proposal lays any interpretation on the membership and I suppose it would be up to the consensus (or ontology war) whether it should be transitive.
- We have lots of natural numbers, e.g., 42 (Q812996) with outgoing triples. I should say they all should have a numeric value (P1181) which could be check with ShEx.
- Natural number are not "instances of instances of natural number", they are instances of natural numbers.
- A further remark: There are apparent a lack of possibility to keep track of which ShEx are created, e.g., at one point it looked like two ShEx was created for humans. I think a property to keep track of ShEx would benefit the ShEx, helping them to navigate the created schemas, i.e., if you are looking for the ShEx for human you can go to Q5 and follow the link to the ShEx page. — Finn Årup Nielsen (fnielsen) (talk) 20:03, 28 May 2019 (UTC)
- The example is new, agreed, but that only makes the need for good examples higher. If there are no good examples of shapes to attach to classes then there is no reason to have this property. Peter F. Patel-Schneider (talk) 23:50, 28 May 2019 (UTC)
- OK, there are "natural numbers" as items in Wikidata, but the shape says that these are instances of instances of natural number (Q21199), which is not correct. And, yes, there should be a check that their numeric value (P1181) is a natural number (if that is possible in ShEx). Peter F. Patel-Schneider (talk) 23:50, 28 May 2019 (UTC)
- If the scope of a shape connected to a class is to be determined after the fact by the community then I'm completely opposed to this proposal. The scope needs to be nailed down explicitly before this property is allowed. Peter F. Patel-Schneider (talk) 23:50, 28 May 2019 (UTC)
- Thanks for the note about "instance of instance of". This is actual not and "instance of instance of" and I think the way that people used this yesterday should be clarified. I would write the line "p:P31 @<instance-of-statement> ;" and similar the below line. In fact, I have changed the name now. I wonder if that clarify this issue? — Finn Årup Nielsen (fnielsen) (talk) 07:07, 29 May 2019 (UTC)
- Sideremark: Interestingly, the current ShEx identifies two statements about 1 (Q199) being a natural number (Q21199). There is a difference in qualifiers (whether zero is the previous). — Finn Årup Nielsen (fnielsen) (talk) 07:10, 29 May 2019 (UTC)
- I think that there is a clash of philosophies here. Wikidata has been very much ontology-as-you-go with no overall coordination and no enforcing of consistency. We have had property suggestions which guide us to some form of consistency, that may also catch errors and vandalism. ShEx would be a next step. While one could imaging a ShEx-police appearing in Wikidata, that roams about enforcing the one and only scheme upon editors and items, I do not think that is what would be happening. I think that ShExs would be gradually built in an interplay with continuous development and refinement of Wikidata items. For instance, the E34 defines Danish nouns which a ShEx could say should always have a grammatical gender. It appears that proper nouns, plurale tantum and the word druk (L46327) form a problematic set where the grammatical gender might exist and can be set, or it might be unknown or have no value. To resolve this problem one should have an interplay between changes in the Wikidata items and the ShEx. Such problems could be discovered by other means, but I think ShEx would also be a help and steer us into a direction of consistency. — Finn Årup Nielsen (fnielsen) (talk) 09:38, 29 May 2019 (UTC)
- Thanks for the note about "instance of instance of". This is actual not and "instance of instance of" and I think the way that people used this yesterday should be clarified. I would write the line "p:P31 @<instance-of-statement> ;" and similar the below line. In fact, I have changed the name now. I wonder if that clarify this issue? — Finn Årup Nielsen (fnielsen) (talk) 07:07, 29 May 2019 (UTC)
- Comments:
- Support - NavinoEvans (talk) 09:28, 29 May 2019 (UTC)
- Support - Moebeus (talk) 11:20, 29 May 2019 (UTC)
- Oppose I'd rather make an item about a shape and link that. --- Jura 09:33, 30 May 2019 (UTC)
- Which advantages do you see in such an approach, compared to this proposal? —MisterSynergy (talk) 09:35, 30 May 2019 (UTC)
- One could describe the shapes in a structured way. Currently, we seem to be getting loads of
#
to do just that. Something we mostly avoided in any other part of Wikidata.--- Jura 09:38, 30 May 2019 (UTC)- @Jura1: As I understand it, the shapes themselves are meant to describe themselves in a structured, RDF-compliant, queryable way. Isn't that meant to be part of the point of them? Or perhaps that's SHACL (Q29377821) ?? Jheald (talk) 17:23, 30 May 2019 (UTC)
- I'm still learning about the syntax .. maybe it's actually possible. Looking at it's current implementation at Wikidata, maybe we can't do it here, at least not with statements as we would usually do it. If we create a datatype for shapes, supposedly we could have several properties in addition to this one .. one could be "shape expression described in this item", "shape expression associated with list". --- Jura 07:02, 31 May 2019 (UTC)
- @Jura1: Yes. I would hope we wouldn't need "shape expression described in this item", because I hope the shape expression (Exxx) would be its own item, and queryable in its own right. (That would depend on whether a ShEx has an RDF representation that could be included in WDQS -- that would certainly be the case for SHACL; I hope it's true for ShEx). But additional properties like "shape expression associated with list" I would certainly see as likely to be useful. I proposed "Shape Expression for class" first, as it seems likely to be the simplest and most common case, and worth a property in its own right. But there will be shape expressions for things identified other than as members of classes, and we will in turn want ways to point to them. Jheald (talk) 08:55, 31 May 2019 (UTC)
- Two posters on Wikidata-l confirm that there is a standard RDF serialisation of ShEx [2]. So it should be straightforward to load this either into WDQS to describe a shape entity; or into an associated triplestore, that could service federated queries from WDQS. Jheald (talk) 16:46, 2 June 2019 (UTC)
- A phabricator ticket is open for this, phab:T225701 Jheald (talk) 09:59, 14 June 2019 (UTC)
- Re "shape expression described in this item": Possibly, but I don't see a plan for that now and there might not be much added value in developing more GUI as it could already be done with Q-entities. --- Jura 10:21, 31 May 2019 (UTC)
- @Jura1: Yes. I would hope we wouldn't need "shape expression described in this item", because I hope the shape expression (Exxx) would be its own item, and queryable in its own right. (That would depend on whether a ShEx has an RDF representation that could be included in WDQS -- that would certainly be the case for SHACL; I hope it's true for ShEx). But additional properties like "shape expression associated with list" I would certainly see as likely to be useful. I proposed "Shape Expression for class" first, as it seems likely to be the simplest and most common case, and worth a property in its own right. But there will be shape expressions for things identified other than as members of classes, and we will in turn want ways to point to them. Jheald (talk) 08:55, 31 May 2019 (UTC)
- Marking as on hold since the datatype is not available. This is not an assessment of the consensus for / against the proposal. − Pintoch (talk) 20:51, 23 July 2019 (UTC)
- Support --Tinker Bell ★ ♥ 20:24, 1 November 2019 (UTC)
- Support Toni 001 (talk) 16:03, 11 November 2019 (UTC)
WikiProject Schemas has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
- Support. Currently, we have around 160 entity schemas and it's difficult to have any information about the existing schemas, especially to avoid create new schemas for already existing ones. I have also created this Phabricator ticket: phab:T243891 for this purpose. Is it possible to bring back this discussion from the current state of 'On Hold'? John Samuel (talk) 11:30, 6 February 2020 (UTC)
- Support I am also in favour of opening the discussion. We have some interesting schemas already on Wikidata, but it really hard to identify that already exist. I am currently just extracting all from 1..n, where I increase n once and while. Having a property would help here. --Andrawaag (talk) 15:22, 6 February 2020 (UTC)
- Support --Sannita - not just another it.wiki sysop 21:25, 6 February 2020 (UTC)
- Support. --Csisc (talk) 23:30, 6 February 2020 (UTC)
- Support for re-opening the discusssion, we have had some more experience by now Pdehaye (talk) 22:23, 9 February 2020 (UTC)
- Support I agree that there needs to be more documentation but Wikidata now has a class for shape expressions so we need to start linking them to items somewhere. This proposal seems like the natural place to start despite the confusion and conflicts to address. Blue Rasberry (talk) 16:29, 12 April 2020 (UTC)
- Support to move beyond on hold. @Pintoch: What do you think? TiagoLubiana (talk) 19:22, 9 May 2020 (UTC)
- Support @Pintoch: --SCIdude (talk) 16:20, 3 November 2020 (UTC)
- Support of being able to add EntitySchemas to items. Oppose to RDF in E-space. I think Juras arguments are valid. This is really a question about how to best model this. We already have a lot of Q-items that describe different structural pieces necessary to construct this wonderful knowledge graph. I see no good reason to use RDF structure in the E-space when we can do it today in Q-space. My impression is that everything that involves WMDE and the team takes a long time to get done, so we might as well follow Juras suggestion and keep RDF in the Q-space and model each E-item there. This offloads the WMDE team which seems to have enough tasks already in their backlog. This is in line with KISS (Q131560) also.--So9q (talk) 11:57, 2 February 2021 (UTC)
- Support Liridon (talk) 19:01, 9 February 2021 (UTC)
- Support Carlinmack (talk) 16:24, 15 June 2023 (UTC)
Awaiting IP Address ranges datatype edit
IP address or range edit
Originally proposed at Wikidata:Property proposal/Organization
Description | single IP address or range of IP addresses |
---|---|
Represents | IP address (Q11135) |
Data type | IP address (phab:T235389)-invalid datatype (not in Module:i18n/datatype) |
Domain | organization (Q43229), |
Example 1 | University of Oxford (Q34433) → 2001:630:440::/44 |
Example 2 | Wikimedia Foundation (Q180) → 198.35.26.0/23 |
Example 3 | Johns Hopkins University (Q193727) → 128.220.0.0/16 |
Example 4 | University of Chicago (Q131252) → 2a03:b600:640::/107 |
Planned use | Move existing values of IPv4 routing prefix (P3761) and IPv6 routing prefix (P3793) into the new field |
See also | IPv4 routing prefix (P3761) and IPv6 routing prefix (P3793) |
Motivation edit
I would like to make a tool in toolforge that will allow a user to input an IP address and get the organization (Q43229) associated for that IP address. Unfortunately, you cannot query a range unless you have the start and end of that range. Based on the discussion in the previous proposal it seems best that a new datatype would be created for this property, one that extends from Quantity. Then organizations will be able to be queried by the IP address. U+1F360 (talk) 20:59, 1 November 2019 (UTC)
Discussion edit
- After the property is created, the old properties should be deprecated. Once all of the data has been migrated, the old properties can be removed. U+1F360 (talk) 21:03, 1 November 2019 (UTC)
- Support. --Tinker Bell ★ ♥ 04:56, 2 November 2019 (UTC)
- Comment if you want to make a tool anyway, then I suggest you do the indexing there. Looking at the Phabricator ticket, there is not a huge appetite for deploying a dedicated datatype for this. − Pintoch (talk) 18:58, 3 November 2019 (UTC)
- Support --Trade (talk) 10:57, 28 January 2020 (UTC)
- Weak support I really don't see much need to replace IPv4 routing prefix (P3761) and IPv6 routing prefix (P3793) with a unified property. But if a unified datatype ever materializes, sure, why not? /ℇsquilo 15:11, 24 August 2021 (UTC)
Awaiting support for lexeme datatypes on Commons edit
depicts lexeme form edit
Originally proposed at Wikidata:Property proposal/Sister projects
Description | lexeme form depicted in the media file |
---|---|
Data type | Form |
Domain | Commons images |
Example 1 | File:Bandera_de_los_Treinta_y_Tres_Orientales.JPG → L562031#F1 invalid ID (L562031#F1) |
Example 2 | File:Protests_in_Puerta_del_Sol,_Madrid_-_Ahora_o_Nunca.jpg → L56980#F1 invalid ID (L56980#F1) |
Example 3 | File:BULLSHIT_rubber_stamp_(mirrored)_on_the_desk_of_a_street_photographer.jpg → L299205#F1 invalid ID (L299205#F1) |
Example 4 | File:Mrs._Susanna_Morin_Swing_160028v.jpg → L9656#F1 invalid ID (L9656#F1) |
Example 5 | File:Vignet_Ende.jpg → L29356#F1 invalid ID (L29356#F1) |
See also | depicts (P180) |
Motivación edit
In Wikimedia Commons there are thousands of images depicting lexemes (a few of them: c:Category:Images by text, not categorised by language yet). Creating a property to indicate the lexemes depicted in a file would be great (IMHO) with regard to structuring linguistic data in media files. This was posted here. Apparently this was also proposed here a few months ago. strakhov (talk) 16:06, 16 July 2022 (UTC)
Discussion edit
Comment To make this really useful, wouldn't it be better if it was "depicts lexeme form"? That way, we would capture more specifically what is on the image. Ainali (talk) 17:31, 16 July 2022 (UTC)
- Comment I don't know. That way it would be captured more specifically what is on the image, for sure, but in the other hand it may make more difficult/complex introducing data. Are there already in Wikidata other properties with the lexeme datatype using forms? strakhov (talk) 10:03, 17 July 2022 (UTC)
- Comment Ah, I see there are a few, indeed. Category:Properties with wikibase-form-datatype. strakhov (talk) 10:22, 17 July 2022 (UTC)
- Comment After a few checks, I can say it's OK for me changing datatype to "form". strakhov (talk) 10:24, 17 July 2022 (UTC)
- Support since the proposal has been change to form. Cheers, VIGNERON (talk) 13:28, 17 July 2022 (UTC)
- Is it only for qualifiers? What if we want to add it as a statement to 🆓 (Q87576444), for example? AntisocialRyan (Talk) 18:14, 17 July 2022 (UTC)
- @AntisocialRyan: It's for lexemes. 🆓 (Q87576444) is a normal item. Lexemes are not qualifiers but their own data type. ChristianKl ❪✉❫ 13:42, 18 July 2022 (UTC)
- I'm aware of that, I meant can we add depicts lexeme form: free (L4087) to the item 🆓 (Q87576444)? As a main statement and not a qualifier. AntisocialRyan (Talk) 15:26, 18 July 2022 (UTC)
- @AntisocialRyan: It's for lexemes. 🆓 (Q87576444) is a normal item. Lexemes are not qualifiers but their own data type. ChristianKl ❪✉❫ 13:42, 18 July 2022 (UTC)
- @AntisocialRyan: In fact this property is not intended to be used as a qualifier, but as a main statement. But not (at least not mostly) here, but in Wikimedia Commons, with media files. strakhov (talk) 16:10, 18 July 2022 (UTC)
- Oh, I see, I misunderstood the examples. Support. AntisocialRyan (Talk) 17:00, 18 July 2022 (UTC)
- @AntisocialRyan: In fact this property is not intended to be used as a qualifier, but as a main statement. But not (at least not mostly) here, but in Wikimedia Commons, with media files. strakhov (talk) 16:10, 18 July 2022 (UTC)
- I would like the description to be more explicit about what depicts means. What's valid and what's not valid as an image for depicts? ChristianKl ❪✉❫ 13:55, 18 July 2022 (UTC)
- @ChristianKl: with regard to the description, mirroring P180's English description, "
word visually depicted in an image, see also P180 for entities depicted
" may work (?). But please feel free to propose a better one. - With regard to what's valid and what not... I guess it's valid when the lexeme form is depicted in the file. Since depicts (P180) has no indication for what's not valid and what is valid, I do not know why this one would need such prescription. Use of P180 is at the discretion of the user and common sense. Anyway, if you believe there are situations when a form is depicted in a file but using this property would not be valid, please indicate them here. strakhov (talk) 15:59, 18 July 2022 (UTC)
- @Strakhov: How is a person supposed to decide whether to use items or lexemes to tackle descriptions? ChristianKl ❪✉❫ 10:23, 19 July 2022 (UTC)
- @ChristianKl: When depicts (P180) should be used and when not IMO falls under the scope of that property (not this one's), and IMO we cannot decide that here (it's a bit tricky and there are still discussions in Commons about when it's appropiate and when not). Anyway, for example, IMHO in the file c:File:Spain Poznan Spain could by You.jpg it would ok using
"depicts lexeme form" = L254265#F1
, but it would not be ok usingdepicts (P180) -> Spain (Q29)
(the image is not even taken in Spain, but in Poland). On the contrary, in the file c:File:A.L. Hickmann's geographisch-statistischer universel-Taschen-Atlas. 1900 (80112515).jpg IMHO would be "OK enough" using"depicts lexeme form" = L36513#F1
anddepicts (P180) -> Spain (Q29)
(both properties). strakhov (talk) 15:20, 19 July 2022 (UTC)
- @ChristianKl: When depicts (P180) should be used and when not IMO falls under the scope of that property (not this one's), and IMO we cannot decide that here (it's a bit tricky and there are still discussions in Commons about when it's appropiate and when not). Anyway, for example, IMHO in the file c:File:Spain Poznan Spain could by You.jpg it would ok using
- @Strakhov: How is a person supposed to decide whether to use items or lexemes to tackle descriptions? ChristianKl ❪✉❫ 10:23, 19 July 2022 (UTC)
- @ChristianKl: with regard to the description, mirroring P180's English description, "
- Comment We should principally be using inscription (P1684) for text on depicted items. Not sure how the present proposal relates to that. And wary that this property might lead to a *lot* of statements per image. Jheald (talk) 15:35, 18 July 2022 (UTC)
- @Jheald:
inscription (P1684) is for entities, concepts, etc, not text: it's language independent, it does not capture different languages being used nor synonyms in the same language (but it captures senses).I guess the problem with someone adding a lot of "depicts lexeme form" statements is not different to someone adding too many P180/P1684P6568 statements (that properties could also be abused). Anyway, if someone believes a big "please, do not try to transcribe full book/newspaper pages such as this one while using this property, try to use common sense" is needed... Cheers. strakhov (talk) 15:59, 18 July 2022 (UTC) - Comment Sorry, I confused inscription (P1684) with inscription mentions (P6568). strakhov (talk) 14:51, 19 July 2022 (UTC)
- You are absolutely right about this proposal not relating to that property. My bad, I did not consider that one. Well, I guess inscription (P1684) is good for transcribing full sentences (they can be added in the file description, file caption, as free text,... too). But it's pretty bad when it comes to crosslinking Wikidata Lexicographical data and Wikimedia Commons. I am interested in the latest. strakhov (talk) 15:20, 19 July 2022 (UTC)
- @Jheald:
- Support with the change to lexeme form, great! Ainali (talk) 08:32, 31 August 2022 (UTC)
- Support in thinking about this, this would open up some interesting possibilities. If we want to document information about what a word looks like written by hand, which can often differ from the digital representation, this would be useful for linking photos showing this to lexeme forms. I uploaded an example of سلسہ just now which I would add this property to if available.
- – The preceding unsigned comment was added by Middle river exports (talk • contribs).
- I've marked this as on hold, because it's not possible to link to lexemes, senses or forms on Commons. - Nikki (talk) 10:49, 11 September 2022 (UTC)
- T304392 on phabricator. strakhov (talk) 15:16, 13 September 2022 (UTC)
- Question What about homonyms? Those might be forms of distinct lexemes or even of the same lexeme, e.g., in the case of inflection. Are editors adding statements with this proposed property to images supposed to work out which of potentially several possible lexemes (and therefore senses) might apply? Which grammatical features apply? What if the inscription is intentionally ambiguous? Or if the image is taken too far out of context? ―BlaueBlüte (talk) 04:38, 1 February 2023 (UTC)
- Comment So far I have just been using subject form (P5830) and subject sense (P6072), see, e.g., https://www.wikidata.org/wiki/Lexeme:L43527 — Finn Årup Nielsen (fnielsen) (talk) 10:52, 25 April 2023 (UTC)
- Adding all images containing a word to the lexeme for the word would be a terrible idea. - Nikki (talk) 13:25, 29 April 2023 (UTC)
- Support, an important property for the connectivity of Wikidata.--Arbnos (talk) 21:04, 17 January 2024 (UTC)