OrganizationRole examples inconsistent with current schema
Two uses of Organization show examples using OrganizationRole in its place, but the schema does not allow for this:
aluminOf
https://schema.org/alumniOf can only be Organization or EducationalOrganization. OrganizationRole is not a subClassOf Organization. Yet Example 2 for role shows AlumniOf using OrganizationRole.
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Delia Derbyshire",
"sameAs": "http://en.wikipedia.org/wiki/Delia_Derbyshire",
"alumniOf": {
"@type": "OrganizationRole",
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "University of Cambridge",
"sameAs": "http://en.wikipedia.org/wiki/University_of_Cambridge"
},
"startDate": "1959"
}
}
alumniOf should have Role or OrganizationRole in its range. or perhaps Role/OrganizationRole should have multiple parents?
hasOccupation
Similarly, Example 2 for Occupation shows Role, but hasOccupation has only Occupation in its range.
{
"@context": "https://schema.org/",
"@type": "Person",
"name": "Albert Einstein",
"hasOccupation": [
{
"@type": "Role",
"hasOccupation": {
"@type": "Occupation",
"name": "Patent examiner",
"occupationalCategory": "23-2099.00"
},
"startDate": "1901",
"endDate": "1906"
},
{
"@type": "Occupation",
"name": "Professor of Physics",
"educationRequirements": "PhD in Physics"
}
]
}
Initially filed in google/schema-dts#143
The questions, and comments, in issue #2777 are also very relevant here.
As referenced in the conformance section of the Data Model documentation, any property, in theory, can expect values Text, URL, Role in addition to those documented.
Following those guidelines, and noting that OrganizationRole is a subtype of Role, those examples are both valid.
However, that is not to say that these capabilities are understood by and obvious to developers.
I believe we could possibly make things a little simpler by adding the Role subtypes - OrganizationRole, EmployeeRole, PerformanceRole, and possibly LinkRole - to the range of appropriate properties (alumniOf, worksFor, memberOf, actor, etc.). Also based upon your second example, there may be a case for a new Role subtype of OccupationRole.
A general highlighting of the usage of Role, by adding it to the range of many properties, would probably increase confusion in return for very little benefit. However, highlighting the use of its already defined subtypes, to add date and other qualifications to certain relationships, would be helpful.
Dependant on support and comments, I would be prepared to draft a PR to apply the limited changes I describe and tweak associated examples.
cc @danbri
I'm using schema-dts with Schema.org for personal projects, and that's why I posted the issue there. I need to use this Role feature in order to express a time period in some properties like hasOccupation and alumniOf. As you said, I hope to see it possible through Role subtypes in the range of the appropriate properties.
I'm not familiar with the schema development process but I'm willing to test the PR.
I also found this confusing... consider the following:
{
"@context": {
"id": "@id",
"type": "@type",
"roles": {
"@id": "https://schema.org/roleName",
"@type": "@id",
"@container": "@set"
}
},
"id": "https://example.com/person/123",
"roles": [
"https://example.com/organizations/456/roles/admin",
"https://example.com/organizations/789/roles/contributor"
]
}
This appears to produce "better" nquads than the examples that rely on the Role type and its subclasses... If this is cancer please tell me now :)
This issue is being tagged as Stale due to inactivity.
- [ ] I know nothing about any of this but fix what needs to be fix . I just happened to accidentally log on to this by browsing through my phone . Which it has been hacked
To which OrganizationalRole is not compatible? Just a suggestion but, I believe the authenticity aspect of identity management my have a hiccup because automation control can not prove identity truly authentic unless DNA genomics becomes hiercy for security globally.
On Thu, Jul 1, 2021, 7:17 PM Irene Jacquez @.***> wrote:
- I know nothing about any of this but fix what needs to be fix . I just happened to accidentally log on to this by browsing through my phone . Which it has been hacked
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/2787#issuecomment-872625823, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFVNUTGKLWXHBEFPZ6NDH3TVUAPZANCNFSM4UVNNUNQ .
BTW, this issue was initially borne out someone using schema-dts and expecting to use Role types in any place it's expected. schema-dts uses TypeScript's type-system to automatically typecheck JSON-LD during development/build-time. The representation of a Role has been included in v1.0.0 which should hopefully help folks in this issue (and #2777) using IDEs and expecting the right code completions.
FWIW, the TypeScript representation of Roles is interesting, and can be written in a closed-form way (simplified):
type Role<TPropertyType extends Thing, TPropertyName extends string> = {
"@type": "Role",
// ... role properties,
[property: TPropertyName]: TPropertyType
}
and any property can be represented as:
type SchemaValue<T, TProperty extends string> = T | Role<T, TProperty> | readonly (T | Role<T, TProperty>)[];
//
type Person {
"@type": "Person",
"name": SchemaValue<Text, "name">
//...
}
This issue is being nudged due to inactivity.