Wikidata:Property proposal/PeriodO period ID
PeriodO period ID
[edit]Originally proposed at Wikidata:Property proposal/Authority control
Description | identifier for a period in the PeriodO time period gazetteer |
---|---|
Represents | PeriodO (Q104904881) |
Data type | External identifier |
Domain | spatio-temporal entity (Q58415929), historical period (Q11514315), temporal entity (Q26907166), occurrence (Q1190554) |
Allowed values | [a-z0-9]{9} |
Example 1 | Eoarchean (Q731470) → 9qtgwckcw |
Example 2 | Spain under the Restoration (Q1044536) → 6c6g3gks2 |
Example 3 | Black Death (Q42005) → pgmrbmd5t |
Example 4 | Sarmatian culture (Q18534333) → 6v8w4pndh |
Example 5 | Korean War (Q8663) → 6c6g3gspp |
Example 6 | Cretaceous (Q44626) → 9qtgwjxcm |
Example 7 | Early Cretaceous (Q752187) → 9qtgwjphz |
Example 8 | Middle Kingdom of Egypt (Q191324) → 6c6g3fz6m |
Example 9 | Cultural Revolution (Q8690) → 6c6g3bsbt |
Example 10 | Safavid dynasty (Q161205) → 6c6g35q9w |
Example 11 | Victorian era (Q182688) → kh9dsxp46 |
Source | https://perio.do |
Planned use | Mix'n'match |
Number of IDs in source | 6847 as of January 19, 2021 |
Expected completeness | always incomplete (Q21873886) |
Formatter URL | http://n2t.net/ark:/99152/p0$1 |
Motivation
[edit]PeriodO is a public domain gazetteer of scholarly definitions of historical, art-historical, and archaeological periods. It eases the task of linking among datasets that define periods differently. It also helps scholars and students see where period definitions overlap or diverge. It is listed in the Library of Congress Subject Heading and Term Source Codes as an approved source terms used to describe the spatiotemporal subject content of a resource. PeriodO identifiers are instances of Archival Resource Key (Q2860403), so in addition to the formatter URL above, we propose to have an ARK formatter (P8054) property value of ark:/99152/p0$1
. Rybesh (talk) 23:01, 11 December 2020 (UTC)
Discussion
[edit]Kommentar @Rybesh: I think this is potentially useful and I have thought about creating this myself but then could not really figure out how to overcome some major issues with PeriodO. Have you seen the previous proposal and there were several issues raised by @PKM: and @Sic19: - how do envision to address these issues, it seems that there are many overlapping entries for periods which result in duplicated entries and overlapping time periods? Hopefully we can resolve these issues through a discussion. Best --Hannes Röst (talk) 15:44, 10 December 2020 (UTC)
- @Hannes Röst: Thank you for the link to the previous proposal; I knew there had been one but couldn't find it. I will address the issues raised by @PKM: and @Sic19: below. Rybesh (talk) 19:13, 10 December 2020 (UTC)
Kommentar How is this different from Archival Resource Key (P8091) (with which it shares a formatter URL)? Mahir256 (talk) 17:01, 10 December 2020 (UTC)
- @Mahir256: An Archival Resource Key (P8091) (ARK) is a type of identifier. PeriodO period IDs are ARKs, but not every ARK is a PeriodO period ID—ARKs are used as identifiers in many different systems (see The ARK Identifier Scheme). The formatter URL for PeriodO period IDs that I put in this proposal also includes the Name Assigning Authority Number (NAAN) (
99152
) and "shoulder" (/p0
) identifying PeriodO as the organization that creates these particular ARKs; this is how PeriodO ARKs can be distinguished from ARKs created by other organizations. (See https://ezid.cdlib.org/id/ark:/99152/p0 and http://n2t.net/ark:/99152 for registration information about this NAAN and shoulder.) Finally, the N2T (Names to Things) resolver service allows turning ARKs into resolvable URLs by prependinghttp://n2t.net/
to them. Rybesh (talk) 19:13, 10 December 2020 (UTC)
- @Rybesh: Thank you for the explanation. Apologies if I am overlooking something obvious here, why is a new property required when you could use Archival Resource Key (P8091) to add these identifiers to items? For example, Eoarchean (Q731470) → ark:/99152/p09qtgwckcw would resolve using P8091. Is there community consensus to create more properties that use ARKs? Using something like content deliverer (P3274) as a qualifier to indicate the source on a P8091 claim could be an alternative. Simon Cobb (User:Sic19 ; talk page) 20:03, 10 December 2020 (UTC)
- @Sic19: That is a good suggestion, and if that approach is recommended as best practice at Wikidata, I'd be happy to recommend it to our partners who want to create statements using PeriodO IDs. However, it seems that the intended use of Archival Resource Key (P8091) (judging from the examples) is not for mapping between Wikidata entities and concepts in external systems, but rather for linking Wikidata entities representing specific objects to documents about or representing those objects elsewhere. Furthermore there are a number of other properties for external identifiers that are ARKs, e.g. Thésaurus de la désignation des objets mobiliers ID (P4979), Bibliothèque nationale de France ID (P268), BAnQ work ID (P1823), and Gallica ID (P4258). In fact, there is even an ARK formatter (P8054) property for use by such properties. The situation with ARKs seems analogous to the situation with URLs: it would be possible to eschew the creation of specialized properties for external identifiers entirely, and to simply use something like reference URL (P854) to point externally (at least for those external identifiers that are resolvable as URLs). But Wikidata does not do that, instead reserving the use of reference URL (P854) for referring to specific documents hosted elsewhere, much as Archival Resource Key (P8091) seems to be intended to be used to point to specific documents in repositories that use ARK identifiers. Rybesh (talk) 23:01, 11 December 2020 (UTC)
- @Rybesh: Who are "our partners" that will be using the property to create statements? Simon Cobb (User:Sic19 ; talk page) 14:43, 12 December 2020 (UTC)
- @Sic19: Various libraries and scholarly linked data projects that are using PeriodO period IDs and also using Wikidata. Rybesh (talk) 21:56, 12 December 2020 (UTC)
- @Rybesh: Who are "our partners" that will be using the property to create statements? Simon Cobb (User:Sic19 ; talk page) 14:43, 12 December 2020 (UTC)
- @Sic19: That is a good suggestion, and if that approach is recommended as best practice at Wikidata, I'd be happy to recommend it to our partners who want to create statements using PeriodO IDs. However, it seems that the intended use of Archival Resource Key (P8091) (judging from the examples) is not for mapping between Wikidata entities and concepts in external systems, but rather for linking Wikidata entities representing specific objects to documents about or representing those objects elsewhere. Furthermore there are a number of other properties for external identifiers that are ARKs, e.g. Thésaurus de la désignation des objets mobiliers ID (P4979), Bibliothèque nationale de France ID (P268), BAnQ work ID (P1823), and Gallica ID (P4258). In fact, there is even an ARK formatter (P8054) property for use by such properties. The situation with ARKs seems analogous to the situation with URLs: it would be possible to eschew the creation of specialized properties for external identifiers entirely, and to simply use something like reference URL (P854) to point externally (at least for those external identifiers that are resolvable as URLs). But Wikidata does not do that, instead reserving the use of reference URL (P854) for referring to specific documents hosted elsewhere, much as Archival Resource Key (P8091) seems to be intended to be used to point to specific documents in repositories that use ARK identifiers. Rybesh (talk) 23:01, 11 December 2020 (UTC)
Kommentar In the previous proposal @PKM: and @Sic19: raised issues about “duplicate” entries in PeriodO. However, while these entries may be similar, they are not duplicates from the perspective of the PeriodO project. The criteria for individuating periods in PeriodO are threefold: 1) temporal extent, 2) spatial extent, and 3) source. Hence there are many “Bronze Age” periods both because this period is understood as having different temporal extents at different places on Earth, and because even at the same spatial location, opinions about the temporal extent of a period may vary. So, this is not a matter of a lack of authority control, but rather authority control at a finer level of granularity: what PeriodO is identifying is periods as conceptualized by different people or organizations. Even if two sources agree on both the temporal extent and spatial extent of a period (as in the case of zj6g8ks9s Bronze Age and r8d9c53w3 Bronzealder), we still record them as separate records, because it is important to know when two different sources agree, as well as when they disagree. Note also that, so that we can trace the genealogy of period concepts, PeriodO records some periods as specifically derived from earlier-defined periods (as in the case of qhb66wrbs Bronze Age, which is derived from zj6g8ks9s Bronze Age).
Given these conceptual differences between how PeriodO treats periods (as individual concepts originating from particular sources) and how Wikidata tends to treat periods (as broad consensus terms), @PKM: and @Sic19: are right to raise concerns about how the proposed property would be used in practice. However, I think that these concerns can be addressed by making clear how the property should be used. First, it should not be used on broad terms like “Bronze Age” that do not specify any particular spatial extent (and hence cannot really specify a temporal extent either, only a relative temporal position). This is why, in my examples, I only selected Wikidata entities that are located both in time and in space (in the case of geologic periods like Eoarchean, the spatial extent is “Earth”). Second, for Wikidata entities that are located both in time and in space, it should be possible for this property to have multiple values. This would be useful in that it would enable Wikidata users to see that there are differing views on the extent of the entity in question, and to get the details about these views from PeriodO if desired. To summarize, I don't think the different conceptual models of Wikidata and PeriodO should be disqualifying for this proposal; in fact this is an excellent case for the use of an external identifier property, as it allows bridging between different views of knowledge. If the conceptual models were identical, there would be no reason to maintain an external identifier, since it would be more efficient to simply move PeriodO into Wikidata en masse.
Rybesh (talk) 19:13, 10 December 2020 (UTC)
- @Rybesh: In the proposal, you state the property will be used for mix'n'match and above you have defined clear guidelines for the usage of the property. Do you think these guidelines will be followed consistently by editors using mix'n'match? Simon Cobb (User:Sic19 ; talk page) 14:43, 12 December 2020 (UTC)
Support This will be a useful identifier to include in Wikidata items. I agree that multiple IDs should be acceptable in items when more granular PeriodO IDs cover a concept that is more broadly covered by a Wikidata item. UWashPrincipalCataloger (talk) 20:17, 20 January 2021 (UTC)
Support I definitely support this and would use it. Just for my own clarity, how exactly would multiple IDs be used in WD? So if we took Roman Republic (Q17167), there are a few options in PeriodO to define the period of the Roman Republic. Would all of these IDs be used for Roman Republic (Q17167)? Would it be also permissible to create separate WD items for more specific definitions of the Roman Republic (for example, if say, a user wanted to associate GLAM objects with a particular geo-spatial and chronological moment)? I don't have a problem with any of these but am just curious about the intended implementationValeriummaximum (talk) 23:52, 2 March 2021 (UTC)
- @ Valeriummaximum: Thank you for your support. What I suggested above was that for Wikidata entities that are located both in time and in space (like Roman Republic (Q17167)) it would be linked to multiple PeriodO IDs. But of course if it were considered useful for there to be a more specific definition of the period of the Roman Republic, distinct from Roman Republic (Q17167), that corresponded to a definition already in PeriodO, then that more specific entity would only be linked to a single PeriodO ID. If someone were to do the latter then obviously they would need to create fingerprint data suitable for disambiguating the more specific definition from the more general concept of the period. Rybesh (talk) 01:04, 3 March 2021 (UTC)
Support This would be a good identifier to have available on WD. I have experience working with PeriodO ids and we include links to them on id.loc.gov at the Library of Congress. Thisismattmiller (talk) 14:13, 3 March 2021 (UTC)
Support I think this is a great idea and would use it in my work with maps. --Librarian lena (talk) 14:37, 3 March 2021 (UTC)
Support Chiming in that this would be a very useful property--PeriodO is a recognized authority for those in my field, and it would be helpful to have my data labeled according to the standards they have established. My cultural heritage project YDEA would commit to using this property as soon as approved! Ahc84 (talk) 14:50, 3 March 2021 (UTC)
Support, an important property for identifiers.--Arbnos (talk) 02:33, 20 March 2021 (UTC)
- @Rybesh, Hannes Röst, PKM, Sic19, Mahir256, Clements.UWLib:
Erledigt as PeriodO period ID (P9350).UWashPrincipalCataloger (talk) 08:10, 23 March 2021 (UTC)
- @ UWashPrincipalCataloger: Fantastic! Thanks everyone for your help and support. Rybesh (talk) 17:14, 23 March 2021 (UTC)
- @UWashPrincipalCataloger, ArthurPSmith: Question: I notice that values for this property are not hyperlinked (see e.g. https://www.wikidata.org/wiki/Q731470#P9350). Any idea why that is? I had thought that since it has a formatter URL defined that it would be hyperlinked. (Also, is this the right place to continue discussion of this property or should that happen on the property talk page now?) Rybesh (talk) 17:29, 23 March 2021 (UTC)
- @Rybesh: Give it a day or so, the links should appear - they seem ok to me now in fact. I'm not sure why there's a delay, but formatter URL's take some time to register in the user interface. And yes discussion should probably move to the new talk page. ArthurPSmith (talk) 18:01, 23 March 2021 (UTC)