Discussions on Religion

I think you're suggesting some new properties on the Diet type for a) religions and b) degree? We could accomplish half of this using existing types and properties by typing (some) diets as Religious Practices. The degree issue is essentially true for all types of religious practices, so any model for degree could probably go there.

We already have relgious leadership.  All the things you mention there would fit into that, though I will admit that eg. someone who as a lay assistant would not.

Religious Leader, at the time the type was created, was meant for leading religious figures like the Pope, the Dalai Lama, etc. Has the definition been relaxed so that religious leader equates religious worker nowadays?

No, it hasn't, and the recent refactoring of the type makes its use for pastors etc. even less workable (although that hasn't stopped some people from using it that way).  A new type is needed, I think.

+1 on new type.

I like it.

Hmm. Looks like I might not have been clear in my previous post. Re: the Religious Leader Appointment type, I think it should be kept, and the new Appointment schema used to supplement it for those leaders that are appointed.

Where are we at with this?  Are we ready to promote to commons?  There was someone asking for it over here: http://www.freebase.com/view/guid/9202a8c04000641f800000000c5a6b8d

No, I just quickly created the base to get the types out of draft.  The base and views can be deleted.

Thanks for the reply. I noticed another thing, Religious Leader doesn't include Person. Is this a desired thing ?

Just a note that a monastery isn't an organisation.  The order that uses the monastery is the organisation.  So you can have a Benedictine monastery founded in 1100 by King Such-and-such, but the organisation is the Order of St Benedict, founded earlier by, um, St Benedict I guess.

Done!

Sounds good, then someperson will add Temple...

What about 'Term for Adherent'? In addition to being slightly less of a mouthful, the examples you give above (Hindu, Muslim, etc.) are all the singular form, not the plural.

Either way, I think Adherent by itself is too ambiguous - I think it invites folks mistakingly typing people as an Adherent, rather than groups of members.

Faye, I saw your post "Characters in parallel/overlapping universes" in Fictional Universes talking about needing separate types. You even wondered whether "the ever-longer list of character types doesn't represent a failure in the data model approach we've taken to represent a fictional existence"

What is the plan to solve this same problem in the views of different religions. Only in the context of Christianity does Jesus have God as a parent. In another religion this assertion is not true. Even in mainstream Christian theology, it is doubted that Jesus's place of birth is Bethlehem. This is not just an issue of resolving controversy. It's an issue of representing the real world where there are different assertions.

Do you plan to create a separate types to make Jesus a "Christian Person" (so his parent can be God), "Muslim Person" (so Jesus' parent is just a human), "Skeptic Person" (where Jesus is not a real historical perseon), etc. How else to get all the separate properties for Parents and Place of Birth? Otherwise the same problem applies: Search results for different universes get all mixed together and the user has the same problem as with Google with too many hits and having to guess at how to sort it out.

Jeff, thanks for the feedback. I think you've realized by now that the Religion domain is somewhat different from most other domains in Freebase. Whereas data on the geocodes of cities and film award winners are cold hard verifiable data, religion is more about self-identification. Data within each religion is meant to be looked at from that religion's point of view, within that context; and if a non-believer, with respect and sensitivity.

Now, religious or not, some topics are controversial simply because of the limitations of our knowledge and in the ways we can find out about them. The birth and death dates of certain historical figures, debates on scientific theories, the origin of some of the nastiest diseases, attribution of celebrated creative works (some claim that Shakespeare was no more than a derivative plagiarizer)... The goal of any reputable data source would be to provide balanced coverage, perhaps highlighting the more accepted perspective (i.e. Shakespeare was one of the greatest poets/playwrights ever lived), but rounding the corners with alternative theories and views for completion. One way to cover different perspectives in Freebase has been the article where conflicting information and different views can be presented. The article on Jesus, for example, does a pretty good job of that. Another vehicle for debate is the Discussion pages.

We have also been thinking of ways to present ambiguous or debated data. If you have specific ideas, we'd love to hear them.

1. You said "Data within each religion is meant to be looked at from that religion's point of view, within that context". Freebase is attractive because of the type system that automatically separates out search results that have different meaning. This is the first thing mentioned in the Freebase introductory video to separate it from Google results where a human has to read and interpret the results to separate them out. So I'm surprised that you say you are not going to use the type system to separate out religious figures, but require users to read and interpret a long article text, or just "know" that the type 'Person' in the Religion domain is different than 'Person' in the other domains. If 'Person' can mean anything, then why isn't 'Harry Potter' typed as a 'Person': He has parents and a birth date too. There was a very good reason why 'Harry Potter' was not typed person, so that searches a bout people don't return hits on him. Isn't that what the type system is for, and why not use it here?

2. You said "If you have specific ideas, we'd love to hear them". In most knowledge representation systems, not only can you assign a topic to a type, you can assign an assertion to a context. So, in a certain fictional work, John F. Kennedy is killed by Fidel Castro. It is a "fact" that the fictional work asserts this, so you want this fact in the system, but you don't want to create a new topic for John F. Kennedy or Fidel Castro. The solution is to go ahead and use the John F. Kennedy topic, but put the assertion in the context of the fictional work. Every search is done in a context - usually the base context of consensus reality (where you would not see this assertion) but you can widen the search to include assertions in other contexts.

Qualifying the context of assertions is such a well-known need of expressive knowledge representation systems, is there a write-up somewhere that explains the Freebase approach to this - or why the Freebase designers decided it isn't necessary?

The types within Freebase are, and will continue to be, a work in process. The lack of contextual assertions in this domain is primarily because we haven't previously found it necessary here. Your questions are good ones and perhaps we will need to add contextual assertions as you suggest. There are tradeoffs we've made in developing a general user interface and a general data model - sometimes specificity is sacrificed for simplicity as we are also interested in the model being easy to understand and contribute to for average users. This isn't to say this is the 'right' way to model these relationships in this case, but its been a guiding principle thus far. An example of another place where we have yet to fully embrace complexity: population data - do we require a user to assert an 'as of date', probably - do we require a user to assert a 'source', possibly - do we require require the user to assert the license under which that piece of data has been shared, possibly - but you can see how it will become more and more intimidating for an average user to assert any simple fact in the system.

That all said, we have, in fact, begun to tackle the contextual assertion idea in the fictional universe domain. It may be that we could use a similar approach here and allow for assertions to be made within the context of specific types, a 'religious perspective' domain for instance. These properties and values that these types confer on a topic may at times conflict with those from other types in the Freebase interface, but specialized applications could specialize their requests and return values from a particular point of view.

Thanks for your thoughtful comments and questions. I hope this answer was helpful.

Thanks Dan for the helpful reply. I notice something very important that I have missed in the fictional character type: some properties are qualified with the fictional universe in which they apply, which is exactly what I hoping you would start doing. For example, the parents property of Fictional Character has you specify the Fictional Universe in which it applies. I will follow up in the fictional universe thread.

I may have spoken too soon. The parents property of Fictional Character is letting me specify the Fictional Universe in which it applies, as I thought. I'll still follow up in the fictional universe thread.