DatasetService resolution fields are arrays

[jbrown-xentity]

Name: James Brown

Affiliation: GSA/data.gov

Type of issue: DatasetService implementation of spatialResolutionInMeters and temporalResolution are both arrays

Issue: in Dataset class they are single strings. Also the keyword field is a single string, but it should be an array.

Recommended change(s):

Resolve by moving to single instance like Dataset class. Should probably do an examination of all fields in this class with Dataset, and consider matching where appropriate.
If there are only added fields in DatasetService, we should consider an extending of Dataset.

[zopalmer14]

I finished my examination of Data Service vs. Dataset, as well as related classes where appropriate, and will post my findings here for the record.

Spatial and Temporal Properties

• spatial - relevant classes: Catalog, Data Service, Dataset, Data Series
  • All are cardinality 0..n; however, Dataset also has the option for a single entry for backwards compatibility
• temporal - relevant classes: Catalog, Data Service, Dataset, Data Series - all same - cardinality 0..n
• spatialResolutionInMeters - relevant classes: Data Service, Dataset, Distribution
  • Dataset and Distribution are 0..1; Data Service is 0..n
• temporalResolution - relevant classes: Data Service, Dataset, Distribution
  • Dataset and Distribution are 0..1; Data Service is 0..n

Data Service vs. Dataset

Note: 28 vs. 57 properties in jsonschema; 29 vs. 48 properties in documentation

• spatial - as mentioned above, Dataset allows for a single entry as well as a list
  • Should we add this allowance to all relevant classes (i.e., Catalog, Data Service, and Data Series)?
• keyword - as mentioned in issue, it is a list in Dataset and a single string in Data Service
  • Should be a list
• spatialResolutionInMeters - as mentioned in issue, it is a single entry in Dataset and a list in Data Service
  • Should be a single entry
• temporalResolution - as mentioned in issue, it is a single entry in Dataset and a list in Data Service
  • Should be a single entry
• geographicBoundingBox - description differs
  • Data Service should be changed to match, Dataset description is more accurate
• accessRights - descriptions differ
  • Data Service should be changed to match, Dataset description is more accurate
• creator - Data Service is a list, Dataset is a single entry; it is also a list in both Catalog and Document
  • For consistency, I guess I'd go with a list. I don't have a strong opinion on this one
• rights - A single entry in Catalog, Dataset, and Distribution, and a list in Data Service
  • Given it's intended use, I actually think it should be a list; see soon to be closed draft PR refactor Dataset.json #87
• category - A single entry in Catalog and Data Service, a list in Dataset
  • Should be a list
• qualifiedAttribution - description differs
  • Data Service should be changed to match, Dataset description is more accurate
• description - required in Dataset but is not in Data Service
  • I guess for consistency we should make it required?

Unique Properties

• Data Service
  • endpointDescription, endpointURL, servesDataset, license
• Dataset
  • dataDictionary, distribution, landingPage, contributor, documentation (page), accrualPeriodicity, hasVersion, image, inSeries, isReferencedBy, liabilityStatement, metadataDistribution, purpose, prev, provenance, relation, issued, sample, scopeNote, source, subject, version, versionNotes
  • Unique Circumstances
    • next (in Dataset documentation but not Dataset jsonschema), status (in Data Service documentation but not Data Service jsonschema)
    • In Dataset jsonschema but not Dataset documentation
      • wasGeneratedBy, supportedSchema, first, hasCurrentVersion, hasPart, replaces, wasAttributedTo

[zopalmer14]

@jbrown-xentity, @neilmb

The long list of discrepancies between the two classes aside, I am going to get started on a PR to resolve the issue (limited in scope to only what James originally documented in the issue), and plan to open separate issues to address each of the other inconsistencies (these will most likely be scoped by property, similar to #93, although I will perhaps bucket the "description differs" ones together).

For the inconsistencies where I am less confident on the correct/recommended change (i.e., the bolded ones), I would appreciate your thoughts on my proposed changes either here or in Slack, whichever you prefer.