In cemeteries, headstones can often be at threat of becoming Unserviceable. This is often due to trees growing in or near the grave and their roots or branches pushing over the headstone.

It is useful to indicate that a Headstone is "Threatened" so family, or others responsible for maintaining the grave site, can be contacted to take steps to avoid the headstone becoming Unserviceable.

Is a new status needed to indicate this status?

The current definition for Archeological dig site is “A physical location under the administration of an Archaeological organization where graves are being exhumed.”

At Toowong Cemetery we perform archeological digs, not to exhume human remains but to discover tombstones, from this and other cemeteries, that were demolished and buried as land-fill.

My suggestion to cater for this is to refine the Archeological dig site definition to,
“A physical location under the administration of an Archaeological organization where graves are being exhumed, or demolished or ruined monuments may be found.”

Document how labels are used within the ontology with respect to aliases and multiple languages. Derives from #10.

The ontology is currently licensed with CC BY 3.0. Consider using the current version of this license CC BY 4.0.

Learn what changed between versions.

Changing to the International version would probably mean you don't need cc:Jurisdiction

Currently these values are set to The Muninn Graves Ontology is meant to deal with the remains of human beings.

The documentation describes four concepts, Graves makes use of the OWL ontological markup and has four basic groups of objects: cemeteries and/or archaeological digs, graves, remains (skeletons or ashes) and monuments

Consider updating to values to cover the full scope, e.g. The Muninn Graves Ontology deals with human remains, graves and places they are found, and monuments that commemorate people or events.

Misspelt in current documentation and v1.5 branch Line 1654

Internal link to ontology terms in documentation are prefixed with term_ e.g. https://rdf.muninn-project.org/ontologies/graves-en.html#term_Ashes

At the term, the link to itself is documented as https://rdf.muninn-project.org/ontologies/graves-en.html#Ashes, without the term_ prefix. This returns you to the top of the page.

The use of an underscore and capitalisation appears to be inconsistent in names. For example:

• Mass_grave, EmptyGrave, WarGrave
• monument_title, siteName
• Servicable, UnServicable (I'll open a separate issue to correct the spelling of these properties #11 )

Is there undocumented logic for the current names? If not, perhaps a naming style should be documented and consistently applied.

The definition for startDate for Dead_people_place is not clear.

I have a number of potential start dates for Toowong Cemetery:

• 1861 - 200 acres was set aside for cemetery purposes
• October 1870 - Cemetery Trust established
• 3 January 1871 - First burial
• 5 July 1875 - Official opened

How can I give guidance on what date has been used? I'm leaning towards using the first burial or official opening date.

"Convenience" is consistently misspelt as "Convinience" in the Specification) and graves.owl.

I'm guessing graves.owl may be used to generate the specification?

https://en.wikipedia.org/wiki/Khachkar

Use OGC method for this. See #2.

The Tumulus rdfs: comment states, "Tumulus is actually the Latin word, but unclear what the appropriate English label is here.”

I’m wondering if “Barrow” is the equivalent English word?

The Brisbane General Cemetery changed its name to Toowong Cemetery. I'm still trying to find the date of the name change.

How is this best represented?

Should there be, either:

1. one cemetery record with an "also known as" property and value ("also known as" is used on the Toowong Cemetery Wikidata entry)

2. two cemetery records, Brisbane General Cemetery from 1871 to ????, and Toowong Cemetery from ???? to null endDate

If the answer is 1., then is an "also known as" property needed on Dead-people-place?

Following on from an email conversation with Rob Warren...

Me:What I didn’t find was the concept of markers. These are labelled metal stakes that represent a person buried in a grave. Is that catered for?

Rob: Good point. Please create a github ticket requesting a "Marker" or "Stake" class. In the current ontology, the top-level class for this is a "Monument". Do you think that "CommemorationObject" would be a better superclass or is a metal stakes a Monument?

In some cemeteries a marker is used to identify each person buried in a grave. Markers are sometimes a stake pushed into the ground beside the grave, or sometimes embedded into the grave surrounds.

In my experience, a Marker identifies one, and only one, person's remains in a grave - there may be different practices followed elsewhere.

I'll open a separate issue regarding the "Monument" or "CommemorationObject" superclass question.

On https://github.com/muninn/graves/blob/v1.5/ontology/graves.owl#L225 #jakes is used for Mary Jackes.

Wondering if there is a spelling error in #jakes or Jackes

eg: Cenotaph grave.

I just came across Linked Open Vocabularies (LOV) and didn't find Muninn/Graves on it. I did find The Muninn Military Ontology on LOV.

My suggestion is to add Muninn/Graves to LOV, and other lists of quality vocabularies, to help build a broader community around the development and reuse of Muninn/Graves.

Sorry for adding this as an Issue but this repository doesn't have a Discussion Forum which may be a better place for these types of suggestions. Alternatively, Labels could be used to categorise Issues but these must be applied by project maintainers.

Fix improper XML serialization of the wikipedia version numbers, get rid of foaf:name and add term stability tags.

I assume you:

• create a tombstone with an id, hasStatus = Serviceable, and a startDate and endDate
• create a tombstone with the same id, hasStatus = Demolished ,and a startDate equal to the demolition date

What I can't workout is how to link them using next-instance and previous_instances as suggested in the Specification.

Edit: Just noticed the need for an example is on the To Do list in the spec 🤪

A number of dcterms:subject statements link to http:// resources, e.g.

<dcterms:subject rdf:resource="http://id.loc.gov/authorities/subjects/sh85066566"/>

The links, when followed, redirect to the https:// equivalents.

Update the Library of Congress resources to use https://

[edit] However the documentation does use http: for the URI, so not sure if this is a good idea.

Wikipedia link https://en.wikipedia.org/wiki/Columbarium

The current comment is spelt "disassmbled"

Following on from #8, Rob asked,

In the current ontology, the top-level class for this is a "Monument". Do you think that "CommemorationObject" would be a better superclass or is a metal stakes a Monument?

I personally prefer "CommemorationObject" as it seems to apply better to things like Plaque and Marker (if implemented). I struggle to consider a metal stake marker used to identify who is buried in a grave as a Monument.

Having said that Monument is a term commonly used in documentation; so I don't mind either way.

Their URI's are wrong, eg: "http://rdf.muninn-project.org/ontologies/Rebuilt".

Pierre de pied and pierre de semelle don't really work in this context. Needed for #21

At Toowong Cemetery we have a number of graves with both Headstones and Footstones.

Is there any value in having a Footstone convenience class that redirects to Tombstone, or should that detail be captured in another way?

At Toowong Cemetery there are at least three Columbarium - walls that have multiple niches, each containing the ashes of person. (I haven't found a niche with multiple people yet). Each occupied niche is covered with a plaque.

To locate a niche, you would need the lat,long for the Columbarium, and then some "map" to find the niche. In my case the niches are arranged in a grid on a single wall but I imagine things could be more complex.

So does the specification already support Columbarium, via:

• the Columbarium or niche is the Grave (which can have a location)
• the Plaque over the niche is a Monument (which can have a location and map)
• the human remains are Ashes in the Grave

I'm not sure if Columbarium needs any additional support via the specification. Thoughts and feedback welcome.

The current Demolished Instance definition is, "The object was destroyed or disassmbled and remains or traces of the object may exists."

A typo was identified in #9 but the "s" is not needed on "exists". Leading to...

"The object was destroyed or disassembled. Remains or traces of the object may exist."

I suggest the following spelling corrections:

• Serviceable
• Unserviceable

skos:definition is now the accepted means of documenting a term.

Deprecate #siteName in favour of something more portable.

From an email conversation with Rob Warren...

Me:I find the definition of Mass Grave surprising- “True if the grave contains more than the remains of one person. This limit is arbitrary and needs debate.” This would make all family graves, “mass graves” which is not what most people would expect. Some references suggest “a burial site containing the remains, often commingled, of numerous persons. The grave is often in the form of a trench, pit, well organised or sectioned and with variable body densities”. Is “family grave” needed?

Rob: My opinion is that a family grave is really a 'family plot'; the family members are buried within a set area but with individual graves, markers and coffins. Originally, my thinking was that mass graves were mass burial pits where bodies where throw in without regard to identity or status, as with plague pits or war crimes sites. I'm willing to move on this.

I suggest that the Mass_grave definition is clarified to align to Rob's reply above, e.g "A mass graves is a burial pit where multiple bodies were thrown in without regard to identity or status. For example: plague pits or war crimes sites."

The definition of Grave - "A single or mass grave with the remains of human beings" adequately supports a family grave or plot where multiple human remains are in a single grave. At Toowong Cemetery graves may be reused by direct descendants under certain conditions.