Wikidata:Property proposal/periphrasis

periphrasis edit

lexeme for periphrastic definition edit

Originally proposed at Wikidata:Property proposal/Lexemes

Done: lexeme sense for periphrastic definition (P7220) (Talk and documentation)

Description	(qualifier) sense of a related lexeme used in periphrastic definition (such "slow" to define "slowly")
Data type	Sense
Domain	Senses of Lexemes
Allowed values	Senses of related lexemes
Example 1	slowly (L7279-S1) -> slow (L1388-S1)
Example 2	traveller (L15579-S1) -> travel (L300-S1)
Example 3	éclairage (L15008-S1) -> éclairer (L15027-S1)
Example 4	employer (L5512-S1) -> employ (L5510-S1)
Example 5	employee (L5513-S1) -> employ (L5510-S1)
Example 6	employee (L5513-S1) -> employment (L5511-S1)
Example 7	employee (L5513-S1) -> employer (L5512-S1)
Example 10	Note: samples above don't include the full statement being qualified (see below)
Planned use	add to some of the fr lexemes
Robot and gadget jobs	could possibly be generated from the gloss in the language of the lexeme

periphrastic definition edit

Originally proposed at Wikidata:Property proposal/Lexemes

Done: periphrastic definition (P7219) (Talk and documentation)

Description	concept used as subject to form a periphrastic definition together with a related lexeme as qualifier (such as "manner" to define "slowly" with the qualifier "slow")
Data type	Sense
Domain	Senses of Lexemes
Allowed values	suitable subjects for definition, with mandatory qualifier (see above)
Example 1	slowly (L7279-S1) -> manner (L7184) L7184-S1 (qualified with: <lexeme for periphrastic definition> slow (L1388-S1)
Example 2	traveller (L15579-S1) -> person (L501) L501-S1 (qualified with: <lexeme for periphrastic definition> travel (L300-S1)
Example 3	éclairage (L15008-S1) -> action (L5374) L5374-S1 (qualified with: <lexeme for periphrastic definition> éclairer (L15027-S1)
Example 4	employer (L5512-S1) -> person (L501) L501-S1 (qualified with: <lexeme for periphrastic definition> employ (L5510-S1)
Example 5	employee (L5513-S1) -> person (L501) L501-S1 (qualified with: <lexeme for periphrastic definition> employ (L5510-S1)
Example 6	employee (L5513-S1) -> person (L501) L501-S1 (qualified with: <lexeme for periphrastic definition> employment (L5511-S1)
Example 7	employee (L5513-S1) -> person (L501) L501-S1 (qualified with: <lexeme for periphrastic definition> employmer (L5512-S1)

link for periphrastic definition edit

Originally proposed at Wikidata:Property proposal/Lexemes

Done: link for periphrastic definition (P7221) (Talk and documentation)

Description	(qualifier) optional qualifier to define the link between the concept and the lexeme
Data type	Sense
Domain	Senses of Lexemes
Allowed values	specific items defining the link
Example 1	slowly (L7279-S1) -> <that is (new item)> (optional)
Example 2	traveller (L15579-S1) -> <who (new item)> (optional)
Example 3	éclairage (L15008-S1) -> <de (new item)> (optional)
Example 4	employer (L5512-S1) -> <concept is active subject of lexeme (new item)>
Example 5	employee (L5513-S1) -> <concept is passive subject/object of lexeme (new item)>
Example 6	employee (L5513-S1) -> <receiver (new item)>
Example 7	employer (L5512-S1) -> <in relation with person>
Example 10	Note: this illustrates an additional qualifier for the statements used previously.

Motivation edit

Following the discussion on Wikidata talk:Lexicographical data, above a detailed proposal. @EncycloPetey, Vive la Rosière: thanks for your input there. Shall we call this "periphrastic definition"?

BTW I used "-S1" in the samples above even though currently "Senses" aren't available and the sense to use eventually might be S2/S3 etc.

This should provide definitions in a structured way (Add your motivation for this property here.)
--- Jura 20:07, 26 August 2018 (UTC)[reply]

Discussion edit

Although "periphrasis" comes close to what we're discussing, so does "circumlocution". I am not certain either word on its own completely embodies the issue, but we can use "periphrastic definition" provided that we maintain a list of local jargon with fuller details of the issue. --EncycloPetey (talk) 21:04, 26 August 2018 (UTC)[reply]
- @EncycloPetey: we could add the others as aliases. Searching around, I found others who use periphrastic definition (L37531), a property label that is primarily meant to be descriptive. In any case, I think this would still be useful and actually better than, e.g. Wikidata:Property_proposal/adjective recently proposed by @Tobias1984:. --- Jura 06:26, 30 November 2018 (UTC)[reply]

Comment (1) I suppose first property proposition should be named "sense for periphrastic definition" instead of "lexeme ..." (2) I thought that there was agreement that properties related to senses are not voted until senses datatype introduction? (3) I'm not sure if it's good idea to vote them together. KaMan (talk) 06:45, 27 August 2018 (UTC)[reply]
- (1) I used "lexeme" as opposed to other entity types. (2) I don't think this is much different to the 15+ others on Wikidata:Property_proposal/Lexemes#Sense that were already voted on or even approved for creation. (3) I put them together on 1 page as I don't think having one without the others would be useful.
  --- Jura 13:26, 27 August 2018 (UTC)[reply]
Comment I like this general idea of finding a way to structure definitions, and this seems like a reasonable starting point for discussion, though I'm not convinced it's there yet. I wish there was a better label for this for one (how many people have ever heard the word periphrasis?) Something like the first two proposals here though seems reasonable. I'm not sure on the third - how does this help? A case where the first two might not be sufficient is employer and employee - in both cases the first property would have value employ and the second would have value person (Q215627) - but what you really need is some way to indicate that employer is the subject of employ while employee is the object - certainly a qualifier with value "<who (new item)>" wouldn't do it...? ArthurPSmith (talk) 17:07, 27 August 2018 (UTC)[reply]
- Nice example, I added it above. I don't think we can do without the second qualifier (I tried to avoid it .. ). We could create values for it as and if we need them and merge them once we notice some are similar. Maybe longer labels are better.
  As for the label, maybe something better comes up. Informally, we could just call it P6000 once it is created ;)
  --- Jura 22:36, 27 August 2018 (UTC)[reply]
Weak oppose. We already have derived from lexeme (P5191) which essentially covers the examples proposed in "lexeme for periphrastic definition". Deryck Chan (talk) 16:36, 20 December 2018 (UTC)[reply]
- derived from lexeme (P5191) isn't meant to define any senses. Maybe you can present samples with qualifiers that would allow an equivalent solution. --- Jura 19:16, 15 February 2019 (UTC)[reply]
  - Agree with Jura, derivation and periphrasis are totally different ; not the same meaning and not the same purpose. V!v£ l@ Rosière ^{/Murmurer…/} 18:03, 10 March 2019 (UTC)[reply]
- Revisiting this per User:Liamjamesperritt's comment on Property talk:P5980 and changing to Neutral. I think Liam is better-placed than I to decide whether we should use object sense (P5980) or create a new property to store the etymon of a periphrastic definition. Deryck Chan (talk) 10:41, 7 May 2019 (UTC)[reply]
Weak oppose per Deryck Chan. KaMan (talk) 07:44, 9 March 2019 (UTC)[reply]
Support can allow to add unfixed way of speaking and metaphorical style. V!v£ l@ Rosière ^{/Murmurer…/} 18:03, 10 March 2019 (UTC)[reply]
Comment @Circeus, Rua, Liamjamesperritt: as active contributors in the field, what's your opinion on this? @EncycloPetey, Vive la Rosière: maybe we could add a few aliases that make the sense of the properties more easily understood. --- Jura 03:33, 23 April 2019 (UTC)[reply]
- Comment @Jura1: You could possibly already achieve this with combines lexemes (P5238). Say for employer (L5512), we can state that it combines lexemes (P5238) employ (L5510) and ‎-er (L29845), and then qualify both with the correct senses using object sense (P5980). Liamjamesperritt (talk) 10:15, 23 April 2019 (UTC)[reply]
  - @Liamjamesperritt: yes, that could work in some cases: depending on how combinations are broken down, it may not be practical. Also, it wont working in the opposite direction: "travel = act of traveling, action of traveler". As mentioned in the initial discussion, it would be good to link this to specific senses, but P5238 is generally used on lexemes directly. --- Jura 04:22, 24 April 2019 (UTC)[reply]
  - I don't think it's necessary to go the opposite direction, as the one direction already encompasses the semantics of the relation. All you need is "traveller" combines lexemes (P5238) "travel" and "-er", ~~and you can already link to specific senses by qualifying the statements with object sense (P5980)~~. Sorry, I realise now that you can't use combines lexemes (P5238) where the subject is a sense. ~~Feel free to give an example that won't work with combines lexemes (P5238).~~ Liamjamesperritt (talk) 04:45, 24 April 2019 (UTC)[reply]
    - It depends what one has in mind. The idea is to do such periphrastic definitions. --- Jura 05:11, 24 April 2019 (UTC)[reply]
    - I added another sample for "employee". --- Jura 17:11, 28 April 2019 (UTC)[reply]
    - @Jura1: I now agree that something like this is missing, and that there is currently no way to fully encode this information with any existing property. However, I still think that it should be achieved with some sort of reference to morphological derivation, as that is what it seems we are trying to communicate. Maybe some way to link each subject sense to the combines lexemes (P5238) property of it's Lexeme?... Or maybe a non-qualifier version of object sense (P5980) where the subject is a sense? Liamjamesperritt (talk) 04:27, 3 May 2019 (UTC)[reply]
    - @Liamjamesperritt: On some level, the values used with the first property proposed above need to be linked (at least indirectly) through P5238, but whatever the standarization done on P5238, I don't think all of the above samples could be covered nor would we necessarily want to have multiple statements for the same P5238-value just to have a place to add qualifiers for these definitions. IMO, Wikidata statements work better if we don't entirely rely on qualifiers. --- Jura 10:16, 5 May 2019 (UTC)[reply]
    - Oppose @Jura1: I proposed a potential alternative at Property talk:P5980. If you can argue that that proposal won't work, then I'll be happy to remove my opposing vote. Liamjamesperritt (talk) 11:45, 7 May 2019 (UTC)[reply]
      - I noted your proposal there and commented there. As noted, it doesn't cover the same objective. Obviously, users could also add this in the glos, but this wouldn't allow to add this in a structured way either. --- Jura 05:27, 14 May 2019 (UTC)[reply]
        @Jura1: I guess it won't hurt to have this property. But before I remove my opposing vote, would you be able to provide some examples on how it would be used in a variety of use cases? At the moment, the majority of the example are just "person" + "action". Does the 'Definition', 'Lexeme', 'Link' pattern work for a variety of cases? How will it work for adjectives or verbs, E.g. "angry" = "feeling anger"; or "(to) shower" = "have a shower". Liamjamesperritt (talk) 03:18, 8 June 2019 (UTC)[reply]
        Yes, I think it should made to work for that too. One could also use "angry" -> "anger" to contrast with "happy" -> "happiness". --- Jura 13:24, 9 June 2019 (UTC)[reply]
        
        @Jura1: It should be fine, I suppose. However, why have you set the Datatypes as Item? Why not just Sense? It may not always be a noun that we need to point to. Liamjamesperritt (talk) 01:32, 22 June 2019 (UTC)[reply]
        @Liamjamesperritt: good question. Sorry for not responding earlier. This topic is moving a bit slowly .. Initially I was to simply use lexeme-datatype for the first one, but the discussion on project with @Vive la Rosière: and others convinced to use sense-datatype instead. For the others, I thought item-datatype would make it easier to query across languages, but in terms of usability of the definition for a given language sense-datatype would probably be the better choice. Indirect queries are still possible (the sense would link to items). --- Jura 09:53, 6 July 2019 (UTC)[reply]

@ZI Jony: recently @Liamjamesperritt: asked a good question. I was going to answer that. Could you re-open it? --- Jura 10:56, 2 July 2019 (UTC)[reply]
- @Jura1: reopened Regards, ZI Jony ^(Talk) 12:49, 2 July 2019 (UTC)[reply]
@Liamjamesperritt, Vive la Rosière: shall we move ahead with sense-datatype for all three? --- Jura 05:47, 24 July 2019 (UTC)[reply]
- @Jura1: I definitely feel that it should be the sense datatype for all three. Best, Liamjamesperritt (talk) 00:57, 4 August 2019 (UTC)[reply]
- @Liamjamesperritt, Vive la Rosière: I updated the datatype. Some of the samples might still need to be revised. For the second property and maybe the third property, a one-of constraint (Q21510859) for each language would probably be helpful. --- Jura 08:45, 4 August 2019 (UTC)[reply]
- @Liamjamesperritt, Jura1: Agree it's better for sense. Fact is, at least in French, we should disambiguate the property somehow since we use periphrasis for the linguistic definition (the proposal here, I guess) but also the stylistic device used in the literary field where the definition is more restrictive. I'm more interested on this second one since it's that one I want to use in a (far far) future project in connection with Wikisource (roughly speaking, extract and reference the literary periphrases attested in the corpus in order to allow the study of the data). V!v£ l@ Rosière ^{/Murmurer…/} 16:56, 8 August 2019 (UTC)[reply]
Comment Thanks. I went ahead and marked them as ready. --- Jura 14:42, 10 August 2019 (UTC)[reply]

@Jura1, EncycloPetey, KaMan, Deryck Chan, Vive la Rosière, Liamjamesperritt:@ZI Jony: Done (after more than 10 days of being marked ready). Now periphrastic definition (P7219), lexeme sense for periphrastic definition (P7220) and link for periphrastic definition (P7221). --Lymantria (talk) 07:18, 23 August 2019 (UTC)[reply]