Human vs Contact

There is an object type of Human and there is an object type of Contact.

My intuition would tell me that Contact is a kind of Human that as more details about how to contact that Human. But in the Contact type relations list there is not a relation to Human, which surprised me. I know I can simply add a relation to each Contract that points to a specific Human, but I figured I would ask the question:

Can you discuss the intent of the two different types (Human vs Contact)?

Thank you so much!

PS - I was not sure if this should be a Support & Q&A or a General Discussion topic, but I made a choice to post to Support & Q&A to start somewhere. Thanks again.

As far as I know all these pre-existing object types and relations are just initial suggestions. There’s bound to be things missing (or weird inconsistencies like you pointed out).

I think the ultimate goal is for users to create their own stuff (and [to have that be more prominent in the UI](Place user-created Types above built-in types in "Store" (improving new Type UI))).

I feel the same as well. I’m not saying this to undermine the team’s work, but I feel it would be best to reduce the number of built in types and relations and keep only few of the most commonly used and well defined ones and remove the others so the users can create them when they want something. This would also reduce the number of duplicate user types created just to modify few relations in built in types. Of-course special types such as File, Audio, Image, etc. cannot be removed. I’m talking about the ones like Bug, Contact, Movie, Book, etc. and the Relations like Rotten Tomato scores, etc. which most users won’t need

3 Likes

OK - thanks. That’s very helpful. And the perspective makes sense that, for now, the developers are giving us a number of example types to play with and learn from.

I agree that primitive types should be included and front-and-center, but custom types should be just suggestions. I imagine in the future any of us could “publish” or make available our exemplar object types so that others can use them and do not need to reinvent the wheel. Hopefully some best practices begin to emerge for relations that tend to be useful or patterns that are worth mimicking.