I usually name the class so that it's very obvious what it is. For example, I would expect ProjectResource to be a child of a project, and ProjectResources should quite obviously be a collection of ProjectResource items.

In the Project class, I would declare the collection as public ProjectResources Resources { ... } so that you're not repeating yourself, then when you use the instance myProject.Resources it reads better than myProject.ProjectResources in my opinion.

I usually follow the same concepts with the property names. Project.Id is better than Project.ProjectId (which looks like a foreign key to me). ProjectResource.ProjectId would be the FK to Project.

I know many of the CSLA examples use the Edit suffix. For our projects Edit is implied, but for read-only objects we use Info as the suffix, and for read-only lists the suffix is List. For collections of editable objects we simply use the plural, such as ProjectResources. POCO data-transfer objects end in Dto, and lists of DTOs end in Dtos, but it's less common to declare a class for this.