In this case, Party is a superclass. Person and Organization are subclasses.
The superclass/subclass situation comes up all the time in the real world.
Unfortunately the relational model doesn't contain inheritance, which is the best way to model this.
Your two answers are variations on one design pattern, called Class Table Inheritance.
In this pattern, each subclass has its own table, and there is one additional table for the superclass, making a total of three tables in this case.
Your two answers differ in that your first answer uses an additional pattern, Called Shared Primary key. In the person and Organization tables, the first column is a foreign key that references the Party table. You didn't mention this, but Party_id can also be declared as the primary key in these two tables. It is guaranteed to be unique. It is generally good practice to declare a foreign key, when that is logically correct.
There is another pattern calls Single Table Inheritance. This pattern was suggested by Vesa Krjalainen in a comment. In this pattern, all the data is combined in one in one table, and individual cells are left NULL when they don't pertain to the instance at hand.
For instance, if Person had an attribute, gender, that doesn't exist for organizations, then organizations would just have NULL for gender.
Single Table Inheritance works well in small and simple cases.
Class Table Inheritance tends to work well in large complex cases.
If you use Shared Primary Key and declare primary keys for all three tables, then the joins you will need will be simple, easy, and fast. Fast because the necessary indexes will be there, and any good DBMS will use them.
If you want to see several questions that are like this one, click on the subtypes tag.