Keep in mind Wikidata's new way of modelling "former" objects

[VojtechDostal]

I just noticed today that Wikidata is slowly changing the way former (demolished or destroyed) objects are modelled. It seems that the instance (of) former entity (and its subclasses) is slowly replaced by a new property P5816 (state of conservation). See this change for example. This discussion seems to suggest it's a preferred new way for the community. We're not in hurry, this is still a minor way of modelling non-existence, but let's keep an eye on the development. Actually, if it is implemented 100% in Wikidata, the query for our app should be performing much quicker if based on P5816 rather than P31 and its subclasses.

[nicolas-raoul]

I had a related discussion yesterday: https://www.wikidata.org/wiki/Wikidata:Project_chat#Add_dissolved%2C_abolished_or_demolished_%28P576%29_or_similar_to_all_former_building_or_structure_%28Q19860854%29%3F

[VojtechDostal]

This is now the predominant way of tracking demolished or destroyed objects in WD. As a result our query no longer works for most cases of these, at least in Czech Rep :-)

[misaochan]

Thanks for letting us know @VojtechDostal ! Just to clarify, you are suggesting that we use P5816 to track which objects exist and which don't, rather than our current method?

[nicolas-raoul]

@VojtechDostal Wonderful! Would you mind editing the query? :-) I suggest keeping both ways for now, until the former way becomes rare.

[VojtechDostal]

@VojtechDostal Wonderful! Would you mind editing the query? :-) I suggest keeping both ways for now, until the former way becomes rare.

I'd love to, but the mentioned query does not do the filtering based on existence/non-existence of objects. It's probably handled somewhere downstream in the app, and is based on ?class, but I am not sure where.

Interestingly, the app also retrieves P576 ("demolished date") - I have no idea if this is used somewhere in the app but IMO not. Maybe we could remove this to speed up the query a little bit. We could also remove P582 ("end time") - this is largely irrelevant for objects in the app.

[nicolas-raoul]

Indeed existence is currently calculated in the app, but if that can be done in the SPARQL directly it would be better. A big OR might be enough?

[VojtechDostal]

Unfortunately it seems I do not understand the app architecture enough to be able to edit the query appropriately.

You'll probably want something along these lines in the query:

OPTIONAL {
{?class wdt:279* wd:Q15893266 .} UNION {?class wdt:P5816 wd:Q56556915 .}
BIND((?state) as ?former) .
}

Anyway I think the query would profit from a thorough check by SPARQL experts, I think it could run a bit quicker if optimized.