Entity Relationship Diagram for Hotel

There are basically just two things here:

1. Your data model, which is the structure of your entities, attributes and relationships.

2. The graphical representation of your data model.

Your data model may be high level (entities/relationships only) or lower level (add in attributes with details of data types) and it may be logical or physical. It all depends on what stage of your design process you're at. The point of a data model is to record your database design, which is just an expression of your business requirements for persisting data.

Crows foot and ERD etc. are just graphical conventions for showing your data model pictorially. The great thing about standards is that there's so many to choose from, and this is also true of graphical conventions. Read this wiki article for a sampling.

Which conventions you choose may depend on what you need to communicate about your model, or it might just depend on what conventions make sense to you.

Don't get too wound up about all the different terminology. It's all just your database design and how you choose to record and communicate it.

The only way I know of is one I can't recommend.

If you convert your EERD into a relational design (with tables, etc.) using some technique like "class table inheritance", you have now disguised the fact that the original EERD contained a generalization/specialization pattern.

If you now turn around and reverse engineer that back to an ERD, you have something that satisfies the requirements of your question. But that's grotesque. It conceals the original intent rather than revealing it. Why would anyone ever want to do that?