5

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.
  • 1
    Here's a list of Ancient Mesopotamian Gods and Goddesses you might find inspiring. I think they are doing an excellent job of presenting all the information you need to get a basic familiarity with a deity. – yannis Dec 29 '15 at 0:58
  • 1
    @Yannis that is perfect. It gave me ideas I hadn't even considered. It's beautiful. The fields 'Further Reading' and 'Time Periods Attested' are excellent! This is completely what I needed. One of my goals is to develop a D3js.org plugin that gives a timeline for each deity as you browse... so you can when they were prominent. I wasn't sure how to visualize this... awesome... thank you so much. – randomblink Dec 29 '15 at 14:47
8

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: Example of a graph (graph theory)

(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.

  • This seems like a great idea, but for the DISPLAY of a populated database / website not as a structure to STORE the data into. Once the database is populated, since I'll be building it in Wordpress and they added REST capabilities, I could utilize something like a TREE structure BASED ON the data. For an example: bl.ocks.org/mbostock/4339083 – randomblink Dec 28 '15 at 18:53
  • 3
    Heh, you should take a closer look at the answer @randomblink, you've completely missed the point here. The suggestion is to look at graph theory concepts for structuring and storing your data, it has nothing to do with how you'll represent your data visually. Also, Wordpress? Eeek! – yannis Dec 28 '15 at 22:27
  • lol... @Yannis I use WP-Types.com Toolset for developing custom post types. I can develop and hash this out fairly quickly (once I have a starting point) and if it grows quick enough that Wordpress doesn't fit I can always use the export options to push the pertinent pieces to another system. But for now... it's free and allows me to get something in place that is both secure and beautiful (if you have premium themes!) with little time upfront to create the look. – randomblink Dec 29 '15 at 14:49
  • 2
    @chaimedes now that I took a second look at what you posted (thanks @Yannis) I like it. It would be a modular development structure. Instead of create a DEITY object in the database I would create a DISCIPLINE object (or function) and then I could catalogue and connect the functions with deities... cultures, gender, etc. It's definitely something to think about. I am not sure how I would do this in my current environment but I'll give everything another look over. Thank you. – randomblink Dec 29 '15 at 14:52
  • 1
    I'm learning D3js.org for both work and personal projects (like this one). I'm hoping that once it is complete I can present a side-page that consumes this DB as a D3 model like this one ( mbostock.github.io/d3/talk/20111116/force-collapsible.html ) or this one ( findtheconversation.com/concept-map ). But first I have to get some data into my DB and then I have to learn D3. I'm still watching tutorials and reading documentation... so we'll see. Either way I like your idea both as an idea for laying this out as well as for display once the DB is populated. – randomblink Jan 5 '16 at 21:40
4

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.

  • But what fields would be relevant to capture? God name... Parents... Children... Siblings... (yes) But what about Disciplines (god of ocean), Famous Feats (created reality, gave fire to humanity), etc. What 'pieces' of data would be best suited to capturing for ALL deities from all mythologies / religions...? – randomblink Dec 28 '15 at 15:08
  • In the bubbles, list major events that happened. – bleh Dec 28 '15 at 15:45
4

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.

  • I actually chose to use the name DEITY in my question here because I didn't want to confuse any non-DB oriented SE Users. I actually have created the initial structure using the term ENTITY. This will allow me to include important mythological characters... priests, demi-gods, etc. I'm not sure how I would avoid using NAME tho... Your statement REALLY resonates (due to the VAST number of gods who have 30+ names). So I'm stumped as to which direction you would go for the initial ENITY object? It requires a 'name' to create it? Right? Intrigued... hoping for more info. – randomblink Jan 5 '16 at 21:43
  • 1
    @randomblink It doesn't have to have a human-readable name unless you require one in your project, a unique ID would suffice. If you do require a readable name, you could go a number of ways. For example, you could attach a single name field to your entity, and fill that field with most-commonly-used or most-widely-known or most-widely-referred name of an entity. – Aleksei Omelaienko Jan 5 '16 at 21:46
  • 1
    @randomblink Personally, if speaking relational, I would create entities, names and entitynames data entities (i.e. tables), AND there would be a nullable (i.e. non-obligatory) default-name-id field in entities, which would refer a name to use as default by it's id. – Aleksei Omelaienko Jan 5 '16 at 21:50
  • Ok... technically, I'm doing this in Wordpress. Why? Because this affords me the luxury of working in a system I'm 100% confortable with and capable of working under the hood. But on top of that, I am using WP-Types which allows you to create custom post types... or custom tables (in a sense). So when I create ENTITIES the field 'name' is how IT identifies them. Maybe I could create an ID concept and use that... Like Zeus would be ZGCR to mean, Z = common name is Zeus, G = geospatial significance is Greece, C and R = Parents are Cronus and Rhea...? I don't know... but I really like your idea. – randomblink Jan 5 '16 at 21:50
  • wp-types.com has a product called Toolset. It allows me to create all of these objects in a GUI. Once created it generates web pages for all of this. Instantly based on the Wordpress concept. This will allow me to create an entity... ZEUS... and there is now a URL to reach this Deity entry... www.domainname.com/entities/zeus as an example (that url doesn't work). But this allows me to (at my leisure) update and expand on these gods... and to bring in others who share an interest to offer them a place to create a repository available to the web. – randomblink Jan 5 '16 at 21:53
3

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.

  • 2
    I do understand that not every culture has gods / deities as I'm used to thinking of them and I'm hoping to expand this structure once I figure out what relevant entities require referencing. I do want to include characters from mythology, but my starting goal is to get a LIST of all relevant gods and god-like beings from mythology and religion. I'm aware that there are some nice sites, but none have 1) the guarantee that I can use their data as I desire 2) the ability to reference each 'db object' and have it display mid-blog / tweet / fb post / etc like I want it to. – randomblink Dec 28 '15 at 18:36
  • 2
    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"... 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'. – randomblink Dec 28 '15 at 18:48
  • @randomblink if I do understand that not every culture has gods / deities as I'm used to thinking of them and I'm hoping to expand this structure once I figure out what relevant entities require referencing, then why do you later say that Think "NAME"... all mythological entities have a name. Some have hundreds. NAME would be a field I could use. DISCIPLINE would be another. – user62 Dec 28 '15 at 19:12
  • 1
    Because when a culture doesn't have a standardized concept of a deity but does have mythologies discussing entities with powers above those of humans then this is what I am referencing. I'm looking for the characters in the stories of the various cultures from history to catalogue. I call them deities because this is the easiest, most understand definition to use to get a group to grasp my topic. Does that make sense? – randomblink Dec 29 '15 at 14:54
  • 1
    Also I broke up my responses to you to show that I was responding to two separate statements you made. Hope that clears up my text. – randomblink Dec 29 '15 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.