remove 'redundant' classes and replace with strings

[zopalmer14]

Summary

Should resolve: #115

Removed classes: LiabilityStatement, LicenseDocument, MediaType, ProvenanceStatement, and RightsStatement

Changes:

• Dataset.liabilityStatement - accept a string instead of LiabilityStatement; update description for greater detail/clarity
• license - accept a string instead of LicenseDocument; update description to include link to resources.data.gov info
• mediaType, format, packageFormat, compressFormat - accept a string instead of MediaType
• mediaType - add IANA link to description
• format - update description to clarify the distinction between it and mediaType
• Dataset.provenance - accept a single string instead of a list of ProvenanceStatements; update description for greater detail/clarity
• rights, accessRights - accept a string instead of RightsStatement
• rights - standardize usage; switch to a list in all relevant classes; update description to clarify usage
• accessRights - sync description across relevant classes

Note:

I will likely open an issue regarding standardizing and clarifying the usage of the various legal metadata properties included in DCAT-US 3.0 as they are quite confusing, have some overlap, and appear sporadically throughout the relevant classes. The changes in this PR are tangentially related to that forthcoming issue/PR, and the changes that I envision making in it. I know a number of CDOC members have raised questions over the legal metadata properties that are available in DCAT-US 3.0 and whether they are capable of fulfilling the M-25-05 requirements, so we can perhaps have that discussion then (i.e., once the PR is ready/reviewed).

Discussion Topics

Should we accept a single entry or a list for Dataset.liabilityStatement, Dataset.provenance, and the license properties? Although a string can be of variable length and include multiple sentences, I can imagine a metadata provider possibly wanting to include multiple links, which I guess they could provide in a comma-separated list that is still only one string.

I'm uncertain on this one. Will probably stick with a single entry unless someone provides a compelling example/argument for a list.

Should we allow any string or enforce the IANA types like in DCAT-US 1.1? There could be further discussion over the implicated properties but at a minimum it would affect Distribution.mediaType and Document.mediaType.

I'm leaning towards enforcing the IANA types, but think we should discuss further

[jbrown-xentity]

The description changes are helpful, and the simplification of classes are great.