Add a "maintainer" property, applicable to datasets (and potentially projects, orgs)

[danbri]

In the context of Google's work around Dataset search, in particular dealing with aggregators, we have encountered a need to distinguish the parties who maintain the information about a dataset within an aggregator (eg. our own Kaggle, but considering also systems like CKAN installations etc.), from the original creators and publishers of the source data.

One suggestion is to add a "maintainer" property, or something similar that more explicitly indicated the nature of the maintenance w.r.t. the above distinctions, i.e. downstream vs upstream maintenance.

It would also be good for this pattern to work for opensource software, where similar issues are common.

The pattern we document at Google currently - see https://developers.google.com/search/docs/data-types/dataset#source-provenance - uses "isBasedOn" to associate an appearance of a dataset with its upstream original

Use the isBasedOn property in cases where the republished dataset (including its metadata) has been changed significantly.

Suggestions welcomed!

[chrisgorgo]

What do you mean by "downstream vs upstream maintenance"?

[danbri]

(notes from IM chat with Chris)

• Opensource distribution terminology e.g. https://wiki.debian.org/UpstreamGuide
  https://serverfault.com/questions/195952/what-does-upstream-and-downstream-mean
• Schema.org is a flat namespace. If we add a property "maintainer" it is potentially usable against hundreds of types. Unless we call it something like datasetMaintainer. So it is worth considering that aspect.
• Also consider a famous dataset that someone packages into Kaggle Eg MNIST. If I make a representation of MNIST within Kaggle, ... I am not the general maintainer of MNIST any more than if I package the CKAN software to run on Raspberry Pi makes me the maintainer of CKAN software in general. Similar issues of derivation/packaging, authority and credit.
• At a minimum I'd suggest these issues require a little explanation in the definition,
  mention isBasedOn, give data and software examples. Apart from this, I think
  "maintainer" could be a useful addition.

[chrisgorgo]

Wouldn't something like this deal with with the upstream/downstream issue?

{
  "@type": "Dataset",
  "name": "derived dataset",
  "maintainer": {
    "@type": "Person",
    "name": "maintainer of the derived dataset"
  },
  "isBasedOn": {
    "@type": "Dataset",
    "name": "original dataset",
    "maintainer": {
      "@type": "Person",
      "name": "maintainer of the original dataset"
    }
}

[danbri]

Yeah that's the pattern I was alluding to.

We need actual definitions. How about:

• new Property "maintainer", definition:
• A maintainer of a [[Dataset]], software package ([[SoftwareApplication]]), or other [[Project]]. It is common for distributions of software and data to be based on "upstream" sources. When "maintainer" is applied to a specific version of something e.g. a particular version or packaging of a Dataset, it is always possible that the upstream source had a different maintainer. The "isBasedOn" property can be used to indicate such relationships. Similar distinctions occur for software, where a package may have dedicated maintainers working on integration into software distributions such as Ubuntu.

[chrisgorgo]

It's a bit odd definition falling into ignotum per ignotum ("maintainer is a maintainer"), but it seems to be in line with other definitions (for example creator). Otherwise the upstream/downstream clarification is ok (but I would add an example to make sure people understand that "isBasedOn" should be applied to the Dataset/SoftwareApplication not the maintainer).

Otherwise allowed types should be Person and Organization?

[chrisgorgo]

Maybe I could send a PR with this to speed things up. Is there an example/template PR adding a new field I could take inspiration from?

[RichardWallis]

Implemented in commit d5034ac