Consider removing ceterms:alternateName from classes where it isn't necessary

[siuc-nate]

In #844 we decided, as a blanket policy, to add ceterms:alternateName to every class that has ceterms:name. I think we may want to revisit this. It seems unnecessary for many of the classes we added it to. For example, certain classes, like Task, rarely have regular names, letalone alternate names. The QData classes I'm currently working on don't need it, either.

The justification for adding it came from this post:

I don't have an example for the other but there's no harm in adding them and if we don't do it now, we'll have to spend time doing it later.

I don't think this is true across the board. We should try to be more demand-driven, especially with a property as broadly-used as Name. Condition Profile, Cost Manifest, Cost Profile, Contact Point, GeoCoordinates, Financial Assistance Profile, Scheduled Offering, and other such classes where the Name isn't particularly important (and usually made up from some recycled template or boilerplate anyway) don't need it. It adds undue clutter to the schema, in my opinion.

I suggest that only classes where ceterms:name is really meaningful, and where alternate names are likely to be present, should have it, such as:

• Credential (and subclasses)
• Organization (and subclasses)
• Learning Opportunity Profile (and subclasses)
• Assessment Profile (and subclasses)
• Occupation
• Job
• Pathway Component (and most(?) subclasses) (most of the underlying things Pathway Components point at would likely have the property)

Some classes are a little more of a gray area. They are unlikely to have alternate names, but if they do, it may be worth capturing:

• Collection
• Collection Component
• Collection Member (I could maybe see keeping it on this one, since Collection Member may often point to things in either the above or below lists)
• Multi-Component
• Pathway
• Pathway Set
• Place
• Work Role
• Transfer Intermediary
• Contact Point

These classes do not, in my opinion, need to keep the alternate name property. Many of these don't even have "real" names in most cases:

• Aggregate Data Profile
• Earnings Profile
• Holders Profile
• Employment Outcome Profile
• Component Condition
• Condition Manifest
• Condition Profile
• Constraint
• Cost Manifest
• Cost Profile
• GeoCoordinates (we don't actually use this class anywhere due to having the Place class)
• Postal Address (we also don't actually use this class anywhere, also due to having the Place class)
• Scheduled Offering
• Support Service
• Task
• Transfer Value Profile
• Data Set Profile
• Data Set Time Frame

[mparsons-ce]

I agree especially where the name is optional.
However, where already implemented, what's the harm?
The API updates would be trivial, however the finder and publisher changes would take some time to remove the properties from tables, and processing.

[siuc-nate]

Fair point. At the very least, we should be more careful about it going forward. For example, I don't think we should add it to the revised QData classes.

[philbarker]

Got to admit, I don't have a strong opinion on this. Taking it off existing classes seems like needless work, and there is a risk that we'll have to add it back at some point. Not automatically adding it to new classes seems sensible.

[jeannekitchens]

I prefer to leave it as is. The deeper we go into use cases, the more granular they become and the more properties get used.