Headstone state questions

[Stephen-Gates]

I've been thinking about my use cases for headstone states. Here's how I'm thinking of using various states (and some questions). Feedback welcome.

1. A headstone was planned but has not been built, or may never be built - 'Unbuilt'
2. A headstone has been built but is not on display - 'Serviceable'
3. A headstone has been built and functioning as planned - 'Serviceable'
4. A headstone is functioning as planned but a tree is threatening to topple it over - 'At Risk' How to indicate a "Threatened" Headstone; Add #AtRisk term to ontology. #48
5. A headstone was removed from a cemetery and placed in storage - 'Abandoned' (or is this still 'Serviceable'?)
6. A headstone was replaced by another. The original headstone is on display in a Museum - 'Abandoned' (or should this be 'Serviceable' as the original headstone is still performing its function i.e. being a physical feature commemorating a person or group of people who have died.)
7. A headstone was removed from a cemetery and placed in storage, then later destroyed and buried elsewhere - 'Demolished'
8. Parts of demolished headstone were discovered and linked to human remains. The full inscription is not visible - 'Demolished', with a hasLocation property to indicate it has been found
9. Parts of demolished headstone were discovered and linked to human remains. The full inscription is visible - 'Serviceable', with a hasLocation property to indicate it has been found. (Is the fact that the inscription is fully visible the thing that causes the status to change, as the headstone function is now being fully performed?)
10. Parts of demolished headstone were discovered, but cannot be linked to human remains. It may have been put on display - 'Ruins'
11. A demolished headstone was rebuilt and put on display - 'Rebuilt' with dates (as a transitory status to 'Serviceable'?)
12. A headstone was functioning as planned but weathering has removed the inscription. The human remains marked by the headstone are known but no record of the inscription exists - 'Unserviceable'
13. A headstone was functioning as planned but weathering has removed the inscription. The human remains marked by the headstone are not known and no record of the inscription exists and hence it cannot be repaired - 'Ruins'

[Stephen-Gates]

Acknowledging the conversation in #48 about hasState values being originally intended for Machinery, which is why there is a value of Burned, but in my mind that is the Cause of an Object being Unserviceable.

hasState applies to Monument (Headstone, etc.), Dead_people_place (Cemetery, etc.) and Container_for_human_remains (Grave, etc.). These could all have a different set of causes why they become Unserviceable.

The Cause of a Monument being Unserviceable could be: Collapsed, Vandalised, Weathered, Being Repaired. These values may not apply to all sub-classes of Dead_people_place. E.g. A Columbarium may collapse but a Cemetery probably won't.

While the set of hasState values, with the addition of Threatened, will support my needs, I'm wondering if the Cause of hasState, needs to be a separate property and if it needs to vary by class or sub-class?

You could go further a split out Threatened from hasState. For example: hasState = Serviceable; threatenedBy = Vegetation, Land Subsidence, etc.

[rwarren2]

The whole 'state' thing is something that I've never been completely happy with....

How would you feel about using the provenance ontology for something along the lines of:
OvergrowingVegetations ( Activity) -> prov:influences -> Monument