ESIPFed / science-on-schema.org

science-on-schema.org - providing guidance for publishing schema.org as JSON-LD for the sciences
Apache License 2.0
113 stars 32 forks source link

Roles of People #119

Open tedhabermann opened 4 years ago

tedhabermann commented 4 years ago

The Roles of People section of the dataset guide has some funny language: "we recommend using the more expressive fields of creator and contribulds of creator and contributor. But using any of these fields are okay."

There are a couple of issues: I don't think contribulds is a word and the second sentence should just be "Using any of these fields is ok." This is confusing because the first sentence seems to outline why we should not be using contributor (it is a secondary author).

BTW are creator and Creator the same property?

Also, the diagram has a dashed double arrow to datacite:ResourceIdentifier. As far as I can tell, there is no mention of resourceIdentifier anywhere in the text. I am also confused by the casing as dataCite element names are lower camel case.

One other question: Can Role be anything?

Also, contributor now seems to be defined as "A secondary contributor to the CreativeWork or Event." rather than a secondary author.

smrgeoinfo commented 4 years ago

Property should be creator (lower case)

The schema.org Role definition in https://schema.org/version/latest/schemaorg-current-http.ttl has no content model for so:Role, except it is subclass of so:Intangible. A so:Role has properties endDate, startDate, and roleName, as well as properties inherited from so:Thing. roleName can have value so:Text or so:URL (so:Name expected value is Text). bottom line... looks like the Role can literally be 'any so:Thing'.

The scope note for contributor is circular ('a contributor is a contributor'). Seems that guidance for 'contributor' in SOSO might be something like 'an agent who has provided significant input to creation of the resource, but who is not included as an author'. With notes along the line of 'use like acknowledgements in typical academic works'.

Role is bound to a creative work through various so: properties that also specify roles: {accountablePerson, author, contributor, copyrightHolder, creator, editor, funder, maintainer, producer, provider, sourceOrganization, sponsor, translator}, thus creating ambiguity on how to encode. We should be clear if the intention is that in SOSO profile only so:creator and so:contributor should be used, with these other roles as so:Role/so:roleName on so:contributor Roles? What other roles are there that SOSO needs beyond the hard types defined by schema.org? One I can think of is 'compiler'

ashepherd commented 3 years ago

Update here with the subclass of Role called [PerformanceRole](https://schema.org/Role#subtypes). From the Person schema.org page, we see this example:

{
  "@context": "https://schema.org",
  "@type": "SportsTeam",
  "name": "San Francisco 49ers",
  "member": {
    "@type": "OrganizationRole",
    "member": {
      "@type": "Person",
      "name": "Joe Montana"
    },
    "startDate": "1979",
    "endDate": "1992",
    "roleName": "Quarterback"
  }
}

From looking at the hasOccupation field of Person class, it says "The Person's occupation. For past professions, use Role for expressing dates."

This seems to suggest that using the Role class might only be necessary for past contexts. With dataset author/contributor maybe we don't need to specify the Role object as our guidelines docs have right now

smrgeoinfo commented 3 years ago

I interpret the "For past professions, use Role for expressing dates." statement to mean that if you want to represent occupations a person has had in the past, use schema:Role because it provides start and end date properties to specify when the person was it that occupation. Doesn't imply its only for past contexts. 'author' and 'contributor' are indeed roles; schema.org is inconsistent because it includes these hard typed roles (they have defined properties in the schema), and also allows soft-typed roles specified by Role/roleName. Multiple ways to do the same thing is bad for interoperability, but we're stuck with it. Role is still useful if you want to specify more specific authorship or contributor roles, like 'leadAuthor', 'coauthor', 'editor', 'compiler', 'reviewer', 'graphicsCreation' etc..., but would need to use a controlled vocabulary for roleName (e.g. https://wiki.esipfed.org/ISO_19115-3_Codelists#CI_RoleCode ) for interoperability,

PerformanceRole is defined " PerformanceRole is a Role that some entity places [I suspect they mean 'plays'] with regard to a theatrical performance," I don't think that's relevant to dataset authorship or contribution. I'd recommend we stick with schema:Role

jaygray0919 commented 3 years ago

Richard Wallace explains it well here:

https://www.dataliberate.com/2015/04/15/the-role-of-role-in-schema-org/