Are Employers CredentialOrganizations?

[philbarker]

We have Job--[offeredBy]->CredentialOrganization.

Do employers meet criteria of "playing one or more key roles in the lifecycle of a credential" or should schema:Organization be range?

[philbarker]

As discussed in the call of 30 Mar: no, employers in general are not CredentialOrganizations. We should create a new class ceterms:Organization, as a superclass of ceterms:CredentialOrganization and ceterms:QACredentialOrganization and equivalentClass to schema:Organization; ceterms:Organization should be added to the range of ceterms:offeredBy.

Proposal:

Create:

URI: ceterms:Organization Label: Organization Definition: An entity such as an association, company, corporation, club, co-operative, labor union etc. Usage Note: For organizations that are involved in the lifecycle of a credential or Quality Assurance use the more specific ceterm:CredentialOrganization or ceterms:QACredentialOrganization. Properties: ceterms:name, ceterms:description, ceterms:agentType, ceterms:address, ceterms:alternateName, ceterms:ctid, ceterms:department, ceterms:email, ceterms:duns, ceterms:fein, ceterms:industryType, ceterms:isicV4, ceterms:leiCode, ceterms:naics, ceterms:parentOrganization, ceterms:sameAs, ceterms:socialMedia, ceterms:subjectWebpage, ceterms:subOrganization

Add:

Subject: ceterms:CredentialOrganization, ceterms:QACredentialOrganization Predicate: rdfs:subClassOf Object: ceterms:Organization

Add:

Subject: ceterms:offeredBy Predicate: schema:rangeIncludes Object: ceterms:Organization

Add:

Subject: ceterms:Organization Predicate: owl:equivalentClass Object: schema:Organization

[jeannekitchens]

Thank you @philbarker . This is important so we can begin supporting owners and offers of pathways, jobs, occupations, tasks, workroles, and outcome data, transfer value where the owners/offerers are not QA or credentialing organizations. Do we need https://credreg.net/ctdl/terms#ownedBy? Also, looking at ownedBy and offeredBy, their domains may need to be updated as well to ensure organizations can offer or own these classes.

[siuc-nate]

@jeannekitchens Do you mean owns and offers? Those would be the properties we would put on a ceterms:Organization class.

[stuartasutton]

While I agree with the proposal to the extent that it creates an Organization class and appropriate new domain designations, I still think we need an Employer subclass to Organization. The reason is that we have circled around Employer as a class now for years. Here we're are looking at employers in the context of Jobs. In the past we've looked at them in terms of soft sorts of quality assurance like preferring, endorsing of credentials etc. etc.. I'm also not fond of a data solution to differentiating using a type property and a controlled vocabulary as suggested yesterday--i.e., I prefer an ontological solution as opposed to a data solution to differentiating things in the world. We have singled out two types of organizations as particular significant in our domain--CredentialOrganization and QACredentialOrganization. I'm suggesting that Employer is a third.

[siuc-nate]

What would be the significant/real differentiating factor that separates an Employer from an Organization at the class level, in a way that can be understood by our partners (publishers and consumers alike)?

I doubt we would even need to add another type to the OrganizationType vocabulary, as any employer is likely to be at least one of the types already listed (e.g. orgType:Business).

[philbarker]

@siuc-nate an Employer would offer Jobs, CredentialOrganization would offer Credentials or a QACredentialOrganization would offer QA functions regarding credentials. (And yes, an organization might be all three, that's reality.)

I think Organization (if still needed) would become a class existing only as a superclass to group Employer, CredentialOrganization and QACredentialOrganization and show they were related to schema.org/Organization, much the same as the Credential superclass.

[siuc-nate]

If all we need is a superclass that never actually gets published or used, then we already have Agent for that.

The problem exists where an organization does more than one thing and doesn't fit neatly into a single subclass of organization (hence the need for the Organization class). But if you have an all-consuming Organization class, I don't think we need any other subclasses of it unless there is a very good reason (e.g. it does something meaningful that an Organization does not). We already have the OrganizationType vocabulary for providing that soft-subclassing (with the added benefit of it allowing for multiple selections).

I'll put it this way: If I were designing CTDL from scratch today, I would have one Organization class with no subclasses at all.

If we're going to add an Employer subclass, then we need to at least give thought to other subclasses of organization we might realistically need and consider whether expanding the OrganizationType vocabulary and using a more generic Organization class would be a better solution, because I have a feeling that it would be.

Adding more (identical) classes adds unnecessary overhead when dealing with properties and the like, as we have already seen with the 20+ subclasses of Credential.

[philbarker]

If all we need is a superclass that never actually gets published or used, then we already have Agent for that.

The Employer class would be used.

I'll put it this way: If I were designing CTDL from scratch today, I would have one Organization class with no subclasses at all. ... Adding more (identical) classes adds unnecessary overhead when dealing with properties and the like, as we have already seen with the 20+ subclasses of Credential.

They're not identical.

It is useful to distinguish betwen different types of things, even if you describe them with the same properties -- especially if you describe them with the same properties. There is no need for another subset of schema.org, but something more expressive is useful.

[siuc-nate]

The Employer class would be used.

Sorry, I meant that in the context of figuring out whether or not we need both Organization and Employer.

They're not identical.

The bar we've set in the past for determining whether or not a new class should be added was "what is the distinguishing factor between [proposed new class] and [some existing class]?". This has helped us (mostly) avoid adding redundant types of Credentials and at the very least gives us some kind of consistent/pre-existing basis for making the determination, and something we can point back to later.

Given that most organizations offer jobs, and we've already agreed that the existing organization classes (as well as the proposed Organization class) offer jobs, I don't see "Employers offer jobs" as being a distinguishing factor that justifies adding an Employer class. Organizations also offer Transfer Value assertions, Competency Frameworks, and many other things; we don't want to end up creating TransferValueOrganization or CompetencyFrameworkOrganization or other such organizations (and again, if it were up to me today, we wouldn't have CredentialOrganization or QACredentialOrganization either - but we're probably stuck with those).

We have the Organization Type vocabulary to allow refining the more general type down and describe what it does in a way that avoids having multiple redundant classes and allows for multiple selections that can even be changed later if necessary.

My suggestion therefore is still to create an Organization class and (if necessary) add Employer to the Organization Type vocabulary.

[philbarker]

I meant that in the context of figuring out whether or not we need both Organization and Employer.

Ah, that looks clear now. Sorry for the misunderstaning.

Given that most organizations offer jobs,

I suspect that is not true, and it also makes me think that I was wrong to suggest the Organization superclass would not be used. The ceterms:subOrganization and ceterms:department would point to things that would be Organizations but not independent legal entities that could emplot people. They're important because often the employment is with a national or international employer, but the work is actually based at a local branch / department.

Other organizations that don't employ are things like clubs, and some partnerships and associations, but I'm not sure we would deal much with them.

Using a classification on a generic class (e.g. Organization Type vocabulary) is a bit of a deadend in RDF. Essentially it's just using a non-standard variation on rdf:type to point to something which is less straightforward to handle as an rdfs:Class. It affects how useful CTDL will be for other standardization efforts.

[stuartasutton]

Nate, we have been at loggerheads over this notion since day one. So, why don't we have one entity in the domain model--"Thing" (the domain of everything) and then use a type property and a concept scheme that lets us say this Thing is this type and that Thing is that type. Run that past developers of ontologies and see how it plays. Reread Phil's comment immediately above multiple times...particularly the the last paragraph:

"Using a classification on a generic class (e.g. Organization Type vocabulary) is a bit of a deadend in RDF. Essentially it's just using a non-standard variation on rdf:type to point to something which is less straightforward to handle as an rdfs:Class. It affects how useful CTDL will be for other standardization efforts."

[siuc-nate]

I am focused on how useful CTDL is; I am not sure where I gave the impression that I am not.

Why don't we have one entity in the domain model--"Thing" (the domain of everything) and then use a type property and a concept scheme that lets us say this Thing is this type and that Thing is that type.

I am not suggesting that, nor have I ever suggested that - that would be a very extreme approach, and extreme approaches are rarely the most useful path. Obviously it is useful to have classes of things. Where we differ is in drawing the line between what does and does not constitute a different class of thing (hence me bringing up the "distinguishing factor" notion that we have used in past scenarios).

If you'll pardon the tangent: The reason I tend to err on the side of vocabularies is because the practical implications (ie implementation details, change management, what it does or doesn't lock us out of doing in the future if/when we change our minds, the corresponding code, guidance/handbooks/diagrams, our ability to explain CTDL to others, etc.) usually go more smoothly with when the differences between two or more nearly-identical (both in properties and usage) things can be encapsulated in a vocabulary. In other words, we are less likely to break systems if we change the items in (or structure of) a vocabulary, we avoid having to list multiple classes when discussing groups of related classes (ie it is much easier to explain or write code that handles "Credential Type" than to explain or write code that individually deals with all 20+ classes of credential), the handbooks don't have to repeat themselves for multiple classes that all look alike, and CTDL is less intimidating and thus easier to digest for our partners.

So no, I am not advocating for an extreme solution like only having "Thing".

What I am trying to do, however, is limit the complexity that keeps creeping its way into CTDL and future-proof things at the same time. I am less concerned about the Employer class on its own than I am about what it means for the addition of future classes that use the same logic. "They offer jobs" is flimsy enough, in my opinion, that you could just as easily justify having "TransferValueOrganization", "CompetencyFrameworkOrganization", "PathwayOrganization", or even "OrganizationOrganization" for something like Ivy Tech. Furthermore, since a general "Organization" class covers everything an "Employer" class would cover, it just doesn't make sense to me to create an Employer class.

It also means we don't have to ask our partners "Are you an employer or do you offer credentials or do you do QA? By the way, you can only pick one." If I were designing the system today, I would also make @type an array, but again, we're stuck with it being a single value unless we can find enough time to overhaul all of our code across the Publisher, Finder, and in the Registry itself.

Should we still decide to do create an Employer class, I will of course go along with it, but I wanted to lay out my thinking on the matter.

In short, it's about balance. If you need a schema that can describe Cars, Trucks, and Planes, you likely wouldn't want to only have a Vehicle class with a vehicleType vocabulary (even though that could be made to work) - but it would be even worse to have RedCar and FastCar and FourDoorCar and ElectricCar and OldCar and LowMileageCar classes (especially if you are constrained to only one @type per object), as each of those attributes would be better suited as vocabularies for describing a single Car class.

Getting back to focusing on the issue/solution: Perhaps we should start with creating an Organization class and see if that is sufficient to cover our needs? It will be easier to add an Employer class later than to add it now and try to un-add it later. The subclass/equivalent class assertions would be updated like so:

• Agent
  • CredentialPerson
  • Organization (equivalent to schema:Organization)
  • CredentialOrganization
  • QACredentialOrganization
  • Employer (if we create it)

[jeannekitchens]

• Agent
  • CredentialPerson
  • Organization (equivalent to schema:Organization)
    • CredentialOrganization
    • QACredentialOrganization

URI: ceterms:Organization Label: Organization Definition: An entity such as an association, company, corporation, club, co-operative, labor union etc. Usage Note: Use for organizations that are not a Credential Organization or a QACredential Organization. Equivalent To: schema:Organization Subclass Of: ceterms:Agent, dct:Agent Properties: ceterms:accreditedBy, ceterms:accreditedIn, ceterms:accredits, ceterms:address, ceterms:administrationProcess, ceterms:agentPurpose, ceterms:agentPurposeDescription, ceterms:agentSectorType, ceterms:agentType, ceterms:alternateName, ceterms:appealProcess, ceterms:approvedBy, ceterms:approvedIn, ceterms:approves, ceterms:availabilityListing, ceterms:complaintProcess, ceterms:credentialingAction, ceterms:ctid, ceterms:department, ceterms:description, ceterms:developmentProcess, ceterms:duns, ceterms:email, ceterms:employee, ceterms:fein, ceterms:foundingDate, ceterms:hasAlignmentMap, ceterms:hasConditionManifest, ceterms:hasCostManifest, ceterms:hasVerificationService, ceterms:identifier, ceterms:image, ceterms:industryType, ceterms:ipedsID, ceterms:isicV4, ceterms:jurisdiction, ceterms:keyword, ceterms:leiCode, ceterms:maintenanceProcess, ceterms:missionAndGoalsStatement, ceterms:missionAndGoalsStatementDescription, ceterms:naics, ceterms:name, ceterms:offers, ceterms:opeID, ceterms:owns, ceterms:parentOrganization, ceterms:qualityAssuranceTargetType, ceterms:recognizedBy, ceterms:recognizedIn, ceterms:recognizes, ceterms:regulatedBy, ceterms:regulatedIn, ceterms:regulates, ceterms:renews, ceterms:reviewProcess, ceterms:revocationProcess, ceterms:revokes, ceterms:sameAs, ceterms:serviceType, ceterms:socialMedia, ceterms:subjectWebpage, ceterms:subOrganization, ceterms:transferValueStatement, ceterms:transferValueStatementDescription

Add:

Subject: ceterms:CredentialOrganization, ceterms:QACredentialOrganization Predicate: rdfs:subClassOf Object: ceterms:Organization

Add:

Subject: ceasn:creator, ceasn:publisher, ceasn:rightsHolder, ceterms:accreditedBy, ceterms:accredits, ceterms:actingAgent, ceterms:affiliatedAgent, ceterms:affiliation, ceterms:approvedBy, ceterms:approves, ceterms:assertedBy, ceterms:conditionManifestOf, ceterms:copyrightHolder, ceterms:costManifestOf, ceterms:department, ceterms:object, ceterms:offeredBy, ceterms:ownedBy, ceterms:parentOrganization, ceterms:participant, ceterms:processingAgent, ceterms:qualityAssuranceTargetType, ceterms:recognizedBy, ceterms:recognizes, ceterms:regulatedBy, ceterms:regulates, ceterms:renewedBy, ceterms:revokedBy, ceterms:subOrganization, ceterms:worksFor Predicate: schema:rangeIncludes Object: ceterms:Organization

Remove:

Subject: ceterms:CredentialOrganization, ceterms:QACredentialOrganization Predicate: rdfs:subClassOf Object: ceterms:Agent, dct:Agent, schema:Organization

Add:

Subject: ceterms:CredentialOrganization Predicate: vann:usageNote Object: For organizations that are not a Credential Organization or a QA Credential Organization, use ceterms:Organization

Add:

Subject: ceterms:QACredentialOrganization Predicate: vann:usageNote Object: For organizations that are not a QA Credential Organization or a Credential Organization, use ceterms:Organization.

[siuc-nate]

These changes have been made in pending CTDL and noted in the history tracking.