Wikidata

Wikidata:Property proposal/located in present-day administrative territorial entity

< Wikidata:Property proposal

located in present-day administrative territorial entity edit

Originally proposed at Wikidata:Property proposal/Place

Descriptionthe item was located in the territory of this present-day administrative unit; however the two did not at any point coexist in time.
Data typeItem
Domaingeographical feature (Q618123)
Allowed valuesitems for places
ExampleMetropolitan Borough of St Marylebone (Q180652) → City of Westminster (Q179351)
Kyle and Carrick (Q6451531) → South Ayrshire (Q209131)
See alsolocated in the administrative territorial entity (P131)
Motivation

Since 11 October 2016 (diff) there has been a constraint on P131 that its subject and its object should have been "contemporary", i.e. they should have coincided or coexisted at some point of history.

However, there is often an interest in being able to search for what former administrative units may have existed within a present-day area. It can also be useful to be able to cleanly separate the historical hierarchy of administrative divisions (for which P131 would be used) from the present day one (which this new property would bridge to); also avoiding anachronism.

I would see this property most commonly being used to place historical subdivisions in a modern context. (As for example in the case shown, mapping a 1975-1996 Scottish district to a current administrative area). Whilst it might also be used for historical places, most often at least a trace of these may still exist, even if only as ruins, which it may be appropriate to use P131 for. Given a choice between the two properties both being valid, P131 should be preferred. But there may be cases where this property feels more appropriate. Jheald (talk) 08:25, 21 February 2017 (UTC)[reply]

Discussion
  Comment Hmm, I think some more general solution is needed here. "Present day" changes all the time :) The question is how to indicate a correlation between something and a location at a distinct point in time. It might be interesting to also note that a present-day building, for example, is in what was previously a completely different "adminstrative territorial entity"... ArthurPSmith (talk) 22:00, 21 February 2017 (UTC)[reply]
Perhaps "location in later administrative territorial entity"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:38, 22 February 2017 (UTC)[reply]
  Comment
@ArthurPSmith, Pigsonthewing, Jura1: Sorry have taken so long to get back to everybody. I started writing up a discussion at Wikidata talk:WikiProject Historical Place about how Wikidata is currently dealing with historical and present-day administrative units for the UK, in part to try to help focus my thoughts for this discussion, and it started turning into one of those horrible TL;DR nightmare posts that just gets longer and longer and starts to become seemingly unfinishable.
I think Jura's right, that the original advice (at least) was to use located in the administrative territorial entity (P131) for all placements of administrative territorial entities ("units"), regardless of whether units may or may not have existed at the same time. So we see things like:
I think that there are three contending desirables that are coming into collision here:
One advantage of this care with dates and terminology is that it should make it easier to identify the exact relationships that held at a particular point in time (if one can rely on them having been consistently applied - which to date one can't (yet)). And these anachronisms that are avoided may I think be a point of particular sensitivity for some users, seeing potential anachronisms as flagrant errors -- signals of carelessness, bad scholarship, lack of reliability for detail.
But how then to treat the unhistorical relations above? What date to put on them? The date that the 'object' entity existed -- even though the relationship was not actually true at that date? (Though one could perhaps argue that the piece of ground of the subject existed, even if its identification with the administrative unit was not contemporary). How should a query looking for relationships that did exist at that time cope with this.
I don't have the answers.
Even limiting relations to those between items that coexisted doesn't solve the issue of separating hierarchies, as several hierarchies may have existed at the same time.
Without care such mixing of hierarchies can also worsen the problem of "leakage" of units into the P131 trees of other higher areas than their own. For example, suppose in a particular hierarchy we have a chain A -> B -> .... E, with units nicely nested. But if we allow jumping between hierarchies, we may create a chain A -> C -> .... E & F, creating an implication (at least with naive use of recursive P131 traversal) that A may be partly contained in F -- even when this is not the case.
This property proposal I thought might have helped, by at least removing anachronistic mappings from "old" to "present day" units from the system.
But I accept it's not a general solution. So if somebody has a more general proposal, or perhaps a more general proposed policy for how all these different kinds of P131 relationships should be handled, I think that would be valuable. Jheald (talk) 11:28, 1 March 2017 (UTC)[reply]
  • @Smalyshev (WMF): what would work best for Jheald's usescases on WDQS? Personally, I'd tend to move anything historic out of P131 or at least define current ones there as preferred. Obviously, it's difficulte to query hierarchies when they include start/end dates. The easiest solution might be to start by creating a property just for one usecase and then see how it can be made to work.
    --- Jura 15:38, 1 March 2017 (UTC)[reply]
@Jura1: Blazegraph does have a SPARQL extension called the Gather-Apply-Scatter (GAS) service, which I haven't yet played with, but have seen Pasleim (talk • contribs • logs) use in queries. I think that can be used to combine recursive searching an undefined number of steps up or down a tree, together with condition checking at each node. (And I think gives some control as to how the search is done). But it's a bit more complicated that just ASK { <X> wdt:P131* <Y> } -- which for most people is how they would probably automatically go about testing whether <X> is in the subtree of <Y>; plus the analogous SELECT query to return every <X> in the <Y>'s subtree.
One could play around a bit with ranking, so that only items linked in the same hierarchy had 'preferred' P131 statements. (Plus perhaps statements relating current relationships between currently existing items to be preferred). But that's quite fragile, depending on everyone to strictly follow the same code, and nobody to change it back because e.g. they don't like the big red font-size for preferred items on Reasonator.
I do think this is more a community question than a technical question, as to we want to semaphore this; and how to present any connections between items existing at different times. Jheald (talk) 17:26, 1 March 2017 (UTC)[reply]
Can you do samples queries that illustrates how your use cases can be covered?
--- Jura 17:59, 3 March 2017 (UTC)[reply]
Jheald (talk • contribs • logs), Pasleim (talk • contribs • logs), I am also extremely interested in seeing a solution to this problem. Also asked at https://stackoverflow.com/q/44301893/how-to-check-for-a-sub-property-at-all-levels-expanded-from-a-sparql-wildcard Syced (talk) 02:11, 2 June 2017 (UTC)[reply]
  • Suggestion - perhaps a different proposal for "located within contemporaneous territorial entity" would be appropriate, leaving the current P131 alone but enforcing the "contemporary" constraint with a new property? ArthurPSmith (talk) 18:00, 1 March 2017 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/located_in_present-day_administrative_territorial_entity&oldid=688912142"