What would be an efficient data structure for cataloging deities?

Question

I'm ready to begin building a databased-website that will provide cataloged details about the various gods, goddesses and pantheons.

I'm looking for the most efficient structure for cataloging them. Such as what data pieces / fields would be generic enough to be important for all deities yet not be majorly unused on the majority of the entries (and it needs to capture those deities who have different names among different cultures). I've read and own multiple books that cover this topic and they each tend to be primarily author-myopic, focusing on the mythologies / religions that the author considered most important while ignoring the countless other deities worshipped by groups of people. I also have seen (and bookmarked) multiple 'God Databases' and they, as well, seem to be stunted, and not allowing for growth.

Basically, any database architecture, metadata, cataloging recommendations would be greatly valued and appreciated.

---

For clarification purposes. I want to use this website / database for a set of specific purposes.

1. Public Domain. Almost every site out there that tracks deities has these disclaimers that stop you from referencing their entries on the deities without some serious contractual agreements, others just say no. I want something that can be referenced by all, for all, and updateable by those who have a legitimate interest.
2. OGP.me. I would like to be able to reference a god in a tweet or facebook post and have a decent image, title, etc. display just like when you post a reference to a blog post, or instagram image. In order to do this, the structure needs to be Open Graph ready. That's part of my goal.
3. Fields. By 'field' I am trying to convey that I am looking for metadata properties, descriptors, etc. that are generic-enough to fit for most deities (and deity-like entities). Think "NAME" (as an example) all mythological entities have a name. Some have hundreds. NAME would be a field I could use. DISCIPLINE would be another. Don't be locked into "text field" concepts. I can offer multiple choice selections. That way, when entering Dionysus I could enter under DISCIPLINE several entries such as 'grape harvest', 'winemaking', 'wine', 'ritual madness', 'fertility', 'theatre' and 'religious ecstasy'. The end desire would be to be able to search for the word 'fertility' and Dionysus (as an example) would pull up.
4. Technical Sidenote: For those more DB-savvy, I am NOT naming this object / table "DEITY" but rather "ENTITY" and I didn't include this information in the initial question to avoid confusion for those not familiar with DB structuring. I've worked with databases for more than 2 decades and I've learned that if you're not comfortable with creating tables, queries, and relationships then DB naming conventions will only confuse you.

Answer 1

I would use a graph.

Graphs (the data structure) allow interconnections between data in a flexible way, and given the often complex relationships depicted in various mythological traditions, I think this would fit the bill quite well.

Each vertex on a graph can in itself be a container, or its own data structure, allowing you to catalog a large amount of information relating to a specific deity in a centralized fashion. Then, the edges connect the vertices in a manner of your choosing: by familial relationship, by historical sources, by common attribute, or any other sensible association.

For instance: Let's say the only information I'm interested in studying is the function of each god, relative to its culture. However, I want to determine exactly when that deity arose in its cultural history. Each vertex then represents one deity, including its name, function, culture(s) of origin, and first known mention. I can then associate each node by divine function, so that, for example, two deities of love will be connected.

Furthermore, since graphs are relations between sets, it's possible to establish subsets, or subgraphs, in which you group the deities by culture, allowing for multiple dimensions of analysis.

Visually, graphs tend to be easy to follow, e.g:

(Subgraphs are usually indicated by use of a different color, or by circling the area.)

Finally, in terms of data processing, graphs are easy to use, with many well-known algorithms for gleaning information from your data, should your list get too long to handle manually.

Hopefully this can be of help. If I've missed anything, let me know.

Answer 2

Family Tree.

Mythology is really just a genealogy from one god to the next generation. Then you could have some bubbles underneath them when the mouse hovers over them to tell them the information. Most people don't know who gave birth to who, or whose son/daughter a couple's are, so it is a lot easier just to have a big family tree.

Answer 3

It would be more productive, perhaps, to think of those not as of fields, but rather as of separate data entities of different kinds. Why? Because there are simply no obligatory singular characteristic which you could apply to any deity. Not even name, as a single deity might have been known under different names in different regions, but it wold still be that very same deity (meaning that both priesthood and laity would recognize that deity as the same they worship). Not even pantheon (most clear and wide-known example would be Greek and Roman mythologies, e.g. Greek Poseidon equals Roman Neptune, Greek Zeus equals Roman Jupiter etc.). So basically, in relational database terms, the only data field deities table should hold would be primary key ID.

And, speaking of deities table, it rather shouldn't be named as such, as while taking into account religious traditions including, but not limited to shamanism, shintoism and taoism, there may or may not be any kind of deities, but there could well be mystical entities of similar significance but vastly different type. So creating a religious-entity-type separate data entity would also be useful.

That approach would also greatly aid extensibility, as it is easier to create a new kind of entity and corresponding relationships to pre-existing entities, than editing existing ones.

Answer 4

I'm ready to begin building a databased-website that will provide cataloged details about the various gods, goddesses and pantheons.

Cool. You should be aware that not every culture has gods and deities the same way that the Greeks had gods and deities (for example, what we refer to as the gods of the Maya were not thought of as gods by the Maya), so right off the bat, you're limiting yourself to specific cultures.

I also have seen (and bookmarked) multiple 'God Databases' and they, as well, seem to be stunted, and not allowing for growth.

Even accounting for the fact that not every culture has a religious structure that lends itself to a "god database", I'm sure that cataloging the pantheon of even one culture takes a lot of work. Theoi.org is a website that focuses on the greek pantheon -- it's an incredibly well produced website, and I'm sure that hundreds of hours went into making it. Unless this is going to be a full time job, I don't see how your database would be any better than the majority of the other databases.

Such as what data pieces / fields would be generic enough to be important for all deities yet not be majorly unused on the majority of the entries (and it needs to capture those deities who have different names among different cultures)

You wont be able to find a "field" that will be applicable to every deity because different cultures have different roles for deities. I suppose the best advice I can give you is to read up about Aarne–Thompson classification systems.

---

My advice to you is, if you really want to create a database of deities (and ignore other characters from mythology, which I'm not sure why you would want to), start with one culture and work your way up.