Wikidata:Property proposal/Abbreviations related to ancient authors and works and to academic works regarding classical antiquity
Jump to navigation
Jump to search
[edit]
LSJ abbreviation[edit]
Originally proposed at Wikidata:Property proposal/Authority control
Withdrawn
DGE abbreviation[edit]
Originally proposed at Wikidata:Property proposal/Authority control
Withdrawn
| Description | abbreviation for an ancient author or work or for an academic work regarding classical antiquity in the Diccionario Griego-Español |
|---|---|
| Represents | Diccionario Griego-Español (Q3026517) |
| Data type | External identifier |
| Domain | human (Q5), written work (Q47461344), academic journal (Q737498) |
| Allowed values | [a-zA-Z\u00C0-\u017F\.]+ |
| Example 1 | Aeschylus (Q40939) → A. |
| Example 2 | Seven against Thebes (Q506546) → Th. |
| Example 3 | Aeschylus of Alexandria (Q4688536) → Aesch.Alex. |
| Example 4 | Aëtius of Amida (Q381956) → Aët. |
| Example 5 | Inscriptiones Graecae (Q673341) → IG |
| Example 6 | American Journal of Archaeology (Q465332) → AJA |
| Source | |
| Planned use | Slow manual addition |
| Number of IDs in source | Thousands (all listed in source pages) |
| Expected completeness | eventually complete (Q21873974) |
| See also | See other properties proposed here |
TLL abbreviation[edit]
Originally proposed at Wikidata:Property proposal/Authority control
Withdrawn
| Description | abbreviation for an ancient author or work in the Thesaurus Linguae Latinae |
|---|---|
| Represents | Thesaurus Linguae Latinae (Q647422) |
| Data type | External identifier |
| Domain | human (Q5), written work (Q47461344) |
| Allowed values | [a-zA-Z\u00C0-\u017F\.\s]+ |
| Example 1 | Avitus of Vienne (Q225201) → Alc. Avit. |
| Example 2 | Ambrose (Q43689) → Ambr. |
| Example 3 | Q3620726 → apol. Dav. |
| Example 4 | Virgil (Q1398) → Verg. |
| Source | https://www.thesaurus.badw.de/en/tll-digital/index/a.html |
| Planned use | Slow manual addition |
| Number of IDs in source | Hundreds (all listed in source page) |
| Expected completeness | eventually complete (Q21873974) |
| See also | See other properties proposed here |
OCD abbreviation[edit]
Originally proposed at Wikidata:Property proposal/Authority control
Withdrawn
| Description | abbreviation for an ancient author or work or for an academic work regarding classical antiquity in the fourth edition of the Oxford Classical Dictionary |
|---|---|
| Represents | Oxford Classical Dictionary (4th rev. ed.) (Q69525831) |
| Data type | External identifier |
| Domain | human (Q5), written work (Q47461344), academic journal (Q737498) |
| Allowed values | [\D\d]+ |
| Example 1 | Aeschylus (Q40939) → Aesch. |
| Example 2 | Seven against Thebes (Q506546) → Sept. |
| Example 3 | Aëtius of Amida (Q381956) → Aët. |
| Example 4 | Inscriptiones Graecae (Q673341) → IG |
| Example 5 | American Journal of Archaeology (Q465332) → AJArch. |
| Source | https://classics.oxfordre.com/staticfiles/images/ORECLA/OCD.ABBREVIATIONS.pdf |
| Planned use | Slow manual addition |
| Number of IDs in source | Hundreds (all listed in source page) |
| Expected completeness | eventually complete (Q21873974) |
| See also | See other properties proposed here |
DNP abbreviation[edit]
Originally proposed at Wikidata:Property proposal/Authority control
Withdrawn
| Description | aabbreviation for an ancient author or work or for an academic work regarding classical antiquity in the fourth edition of Der Neue Pauly |
|---|---|
| Represents | The New Pauly (Q12899625) |
| Data type | External identifier |
| Domain | human (Q5), written work (Q47461344), academic journal (Q737498) |
| Allowed values | [a-zA-Z\.\s]+ |
| Example 1 | Aeschylus (Q40939) → Aischyl. |
| Example 2 | Seven against Thebes (Q506546) → Sept. |
| Example 3 | Aëtius of Amida (Q381956) → Aet. |
| Example 4 | Avitus of Vienne (Q225201) → Alc. Avit. |
| Example 5 | Ambrose (Q43689) → Ambr. |
| Example 6 | Virgil (Q1398) → Verg. |
| Source | https://referenceworks.brillonline.com/entries/der-neue-pauly/erweitertes-abkurzungsverzeichnis-COM_004 |
| Planned use | Slow manual addition |
| Number of IDs in source | Hundreds (all listed in source page) |
| Expected completeness | eventually complete (Q21873974) |
| See also | See other properties proposed here |
Motivation[edit]
As indicated in en:Abbreviations for Classical authors and texts, LSJ and DGE (usually in accordance, but rare divergences make it useful to have both of them) are the main sources for abbreviations of ancient Greek authors and works, while TLL is the main source for abbreviations of Latin authors and works and OCD covers both fields; additionally, as indicated in de:Liste der Abkürzungen antiker Autoren und Werktitel, DNP is the main source for abbreviations in both fields used in German-speaking countries. These abbreviations are fundamental as they are the standard way to refer to ancient literature in academic publications, so it is vital to start covering them. Additionally, these five sources offer a wide range of abbreviations for reference works and academic journals which are, as the previous, widespread in academic publications, so covering them too is very important.
According to the definition of datatype external-id as "String that represents an identifier used in an external system", I think that datatype external-id is perfectly fit for all of these; while using short name (P1813) might be a viable solution, its use is in fact imprecise (because these abbreviations are not monolingual text, but strings that these vocabularies use as identifiers; we should also keep analogy with botanist author abbreviation (P428), which is an external-id) and practically inefficient (because indicating which is the source of the abbreviation in the reference makes it much more difficult to query these data). Epìdosis 15:30, 17 August 2020 (UTC)
Notified participants of WikiProject Ancient Greece
Notified participants of WikiProject Ancient Rome --Epìdosis 15:32, 17 August 2020 (UTC)
Discussion[edit]
Neutral as I told you months ago, I strongly support the idea of a property for thoses abbreviations and I thank you for this proposition. However, I'm still unconvinced by the idea of having multiples properties for this, as a lot of publications/institutions may have a valid claim for their own system. For example, the french-speaking academic world might find desirable to have those of the Dictionnaire Illustré Latin-Français (Q1248405) or Dictionnaire grec-français (Q3026752), and the German Archaeological Institute (Q695302) also has its own far-reaching system, at least for journals. I would find more desirable to have a unique property for abbreviation (or maybe one for ancient authors, one for ancient works and one for modern academic works/journals), and record each variant with a different value within the same property. --Jahl de Vautban (talk) 16:36, 17 August 2020 (UTC)
- Can we have a single dedicated property (less generic than P428) accepting multiple values with clear qualifiers and use these ones as sources for them? Problem of non-standardized abbreviation is transversal, finding an elegant solution can be very useful in other fields, IMHO, that's why I want to dig here. I assume also that your proposed approach could maybe be better to reduce timing for some queries? Will my suggestion be problematic in that case?--Alexmar983 (talk) 01:21, 18 August 2020 (UTC)
- I suppose you mean short name (P1813). I think that is suitable for such abbreviations even one uses the language code "und" or "mul".
- There are also code (P3295) and catalog code (P528). Obviously, there is still room for dedicated properties like the ones proposed here. --- Jura 01:53, 18 August 2020 (UTC)
- @Jahl de Vautban, Alexmar983: So, as I said 1) using pre-existent short name (P1813) or 2) creating one new property (how defined? abbreviations used by vocabularies?) or 3) creating three new properties ("one for ancient authors, one for ancient works and one for modern academic works/journals") would implicate that: 1] we would use a property with datatype "monolingual text", but these are strings that vocabularies use as identifiers, so they are fit for the definition of datatype "external-id" (a "String that represents an identifier used in an external system") and there is an analogy with botanist author abbreviation (P428); 2] basing the indication of the source on qualifiers and/or references, we would have problems of timing with queries (while the proposed approach could is surely better to reduce timing for some queries). I would have no problem with having some more properties for abbreviations of French dictionaries, given that they enjoy significant usage. --Epìdosis 13:31, 18 August 2020 (UTC)
- I don't think it can be "external-id" datatype if you combine different, potentially conflicting authorities. author citation (zoology) (P835) has that problem too. --- Jura 13:37, 18 August 2020 (UTC)
- (conf.) Sorry, I meant "less generic than P1813", I copied and pasted the wrong one. I understand that that is not enough. In any case, if no elegant or efficient solution is possible, I am fine with all the properties, but I hope we can still work towards something else. We noticed clearly only because you proposed them together, which is still better than having them randomly cumulating in any case. So
Support.--Alexmar983 (talk) 13:40, 18 August 2020 (UTC)
- (conf.) @Jura1: Sure, "if you combine different, potentially conflicting authorities" the datatype "external-id" seems unfit to me too. But this would regard the scenarios 2 and 3, not my proposal of 5 new properties each one specific for a precise vocabulary. --Epìdosis 13:43, 18 August 2020 (UTC)
- @Epìdosis: I don't know enough of database management nor do I use queries on Wikidata (in fact I probably don't use Wikidata the way it's supposed to be) to judge on those criterias, so I'll trust you on technical issues. So Support if its technically the most efficient way, but that means that for some (like Verg. for Virgil or Hdt. for Herodotus) we will have 3 or 4 properties saying the same thing. Still, I got a question for which I would like to hear from you : How can we effectively assess the widespread use of an abbreviation system? Were calculations made about that? The Wikipedia page you linked above are very assertive but don't source their claims. Now I won't dispute any of the above-proposed properties, though I never heard of the DGE being a reference before, but for future ones that might be desirable. --Jahl de Vautban (talk) 14:51, 18 August 2020 (UTC)
- Independently of creating one or the other of the above properties, instead of using code (P3295) and catalog code (P528), we could create a "entry in abbreviation table" property and use a qualifier to link the item for the work. This would have the advantage that all statements were with the same property, but can still be selected by work. --- Jura 10:48, 19 August 2020 (UTC)
- @Epìdosis: I don't know enough of database management nor do I use queries on Wikidata (in fact I probably don't use Wikidata the way it's supposed to be) to judge on those criterias, so I'll trust you on technical issues. So
- (conf.) @Jura1: Sure, "if you combine different, potentially conflicting authorities" the datatype "external-id" seems unfit to me too. But this would regard the scenarios 2 and 3, not my proposal of 5 new properties each one specific for a precise vocabulary. --Epìdosis 13:43, 18 August 2020 (UTC)
- (conf.) Sorry, I meant "less generic than P1813", I copied and pasted the wrong one. I understand that that is not enough. In any case, if no elegant or efficient solution is possible, I am fine with all the properties, but I hope we can still work towards something else. We noticed clearly only because you proposed them together, which is still better than having them randomly cumulating in any case. So
- I don't think it can be "external-id" datatype if you combine different, potentially conflicting authorities. author citation (zoology) (P835) has that problem too. --- Jura 13:37, 18 August 2020 (UTC)
- @Jahl de Vautban, Alexmar983: So, as I said 1) using pre-existent short name (P1813) or 2) creating one new property (how defined? abbreviations used by vocabularies?) or 3) creating three new properties ("one for ancient authors, one for ancient works and one for modern academic works/journals") would implicate that: 1] we would use a property with datatype "monolingual text", but these are strings that vocabularies use as identifiers, so they are fit for the definition of datatype "external-id" (a "String that represents an identifier used in an external system") and there is an analogy with botanist author abbreviation (P428); 2] basing the indication of the source on qualifiers and/or references, we would have problems of timing with queries (while the proposed approach could is surely better to reduce timing for some queries). I would have no problem with having some more properties for abbreviations of French dictionaries, given that they enjoy significant usage. --Epìdosis 13:31, 18 August 2020 (UTC)
- Can we have a single dedicated property (less generic than P428) accepting multiple values with clear qualifiers and use these ones as sources for them? Problem of non-standardized abbreviation is transversal, finding an elegant solution can be very useful in other fields, IMHO, that's why I want to dig here. I assume also that your proposed approach could maybe be better to reduce timing for some queries? Will my suggestion be problematic in that case?--Alexmar983 (talk) 01:21, 18 August 2020 (UTC)
- Hello Epìdosis
2 things:
- I am also puzzled by the idea of identifiers. There is already entry in abbreviations table (P8703), so
Oppose. Otherwise, why not an another specific prop with the possibility of multiple values? As constraints: language and ref required. Then, if you want, you can also add statement is subject of (P805). If I take the newly created Oxford Classical Dictionary ID (P9106) (which should be included in your OCD proposal above) and Aeschylus (Q40939) (your example), there will be two identifiers: 1 for P9106 and 1 for an abbreviation, and for the same site 
. Some of your proposals do not have enough IDs to make them properties of external-id. A property of abbreviations would bring them all together. - If ever your proposals were to succeed, I checked the RegEx of LSJ and OCD. There are also spaces and numbers in LSJ, so I suggest
[-\w\x{00C0}-\x{017F}\.\S]{1,52}. Also, I suggest.{1,52}for OCD. The rest should be checked more thoroughly. Cordially.
—Eihel (talk) 18:46, 3 February 2021 (UTC)
- @Eihel: Thanks for resuming this! I've reflected on the problem and I've effectively concluded that the use of entry in abbreviations table (P8703) (which didn't exist when I made the proposals) with qualifier used by (P1535) fits well the initial scope. The creation of these properties, although they would have a sufficient number of IDs (hundreds each) and they would have some benefits (i.e. easier queries in order to find intersections between dictionaries), is in fact not so useful (particularly because there can't be a formatter URL, and also because in many cases the properties would have in fact the same value). So, I withdraw the proposals. Good evening, --Epìdosis 19:01, 3 February 2021 (UTC)
- ps. Have you noticed the hexadecimal notation of RegEx for next time? Ciao
—Eihel (talk) 19:29, 3 February 2021 (UTC)
- ps. Have you noticed the hexadecimal notation of RegEx for next time? Ciao
- I am also puzzled by the idea of identifiers. There is already entry in abbreviations table (P8703), so
Not done Withdrawn by the applicant. —Eihel (talk) 19:30, 3 February 2021 (UTC)