muninn / graves Goto Github PK
View Code? Open in Web Editor NEWAn ontology to markup information on human remains, graves, cemeteries, monuments and cenotaphs.
Home Page: https://rdf.muninn-project.org/ontologies/graves-en.html
An ontology to markup information on human remains, graves, cemeteries, monuments and cenotaphs.
Home Page: https://rdf.muninn-project.org/ontologies/graves-en.html
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:
I'm not sure if Columbarium needs any additional support via the specification. Thoughts and feedback welcome.
skos:definition is now the accepted means of documenting a term.
Wikipedia link https://en.wikipedia.org/wiki/Columbarium
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?
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 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?
Use OGC method for this. See #2.
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.
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.
Their URI's are wrong, eg: "http://rdf.muninn-project.org/ontologies/Rebuilt".
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.
I suggest the following spelling corrections:
I assume you:
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 🤪
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.
eg: Cenotaph grave.
The definition for startDate for Dead_people_place is not clear.
I have a number of potential start dates for Toowong Cemetery:
How can I give guidance on what date has been used? I'm leaning towards using the first burial or official opening date.
Pierre de pied and pierre de semelle don't really work in this context. Needed for #21
Fix improper XML serialization of the wikipedia version numbers, get rid of foaf:name and add term stability tags.
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."
"Convenience" is consistently misspelt as "Convinience" in the Specification) and graves.owl.
I'm guessing graves.owl may be used to generate the specification?
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?
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 current comment is spelt "disassmbled"
Misspelt in current documentation and v1.5 branch Line 1654
Document how labels are used within the ontology with respect to aliases and multiple languages. Derives from #10.
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.”
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
Deprecate #siteName in favour of something more portable.
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.
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:
one cemetery record with an "also known as" property and value ("also known as" is used on the Toowong Cemetery Wikidata entry)
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?
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.