Feedback on common core schema

[jpmckinney]

In general, great work! A few questions/comments:

• contactPoint is being added to DCAT. To maintain conformance, consider renaming the person property to contactPoint.
  • see Various DCAT implementation fixes #57
• I prefer schema:email to foaf:mbox, but either is fine. Just letting you know that you can call that property email as the two properties are owl:sameAs, I believe.
• Did systemOfRecords come from an existing vocabulary, or did you need to mint it for your use case? If it is new, it would be good practice to mention it, as you've done for accessLevel.
  • fixed Updated schema.md #60
• dcat:size has been renamed to dcat:byteSize, which is a clearer term. As mentioned in corrected file size to proper use of B vs b and M/G vs m/g #32, byte size is much less prone to error than various abbreviations for byte size, like GB, GiB, etc.
  • size has been removed 🔥 the size field #114
• Dublin Core has a different, more flexible way of expressing dct:temporal. You may want to consider making it an object with "start" and "end" fields. This would also solve Suggested formatting around allowing open ranges for the temporal property #43
• FYI, granularity was dropped from DCAT because it was underspecified and publishers simply didn't know how/when/why to use it. You may want to drop it as well unless you have a very clear use case in mind (that others share).
  • fixed Drop granularity #115
• dataDictionary was also dropped due to inconsistent usage. dataQuality was dropped from DCAT for similar reasons, but I see you have a clear definition of what it means, so it makes sense to keep that one. Just flagging these to let you know that you can very likely get rid of them if you were already on the fence about them.
  • see Various DCAT implementation fixes #57
• WebService and Feed are classes in DCAT (subclasses of Distribution to be specific), not properties. To be consistent, you can have a @type field (see DCAT JSON structure #23 for why this term should be used) on each Distribution which would be used to say whether the distribution is a WebService, Feed or Download. This also solves the issue of having multiple APIs and feeds for the same dataset, which is not handled by the current spec.
  • see Various DCAT implementation fixes #57
• As mentioned in Need consistent JSON serialization for properties with (0,n) + (1,n) cardinality #39, please use arrays and not comma-separated values.
• It would be cool to add the three properties mentioned in DCAT JSON structure #23 (@context, @id and @type)

Ref.: the latest version of DCAT

[jpmckinney]

Comments re: ranges:

• Please recommend ISO 8601 for all date fields. ISO 8601 can do reduced dates (e.g. YYYY, YYYY-MM or YYYY-MM-DD) in addition to all your usual long-form dates (and more) and is well supported by a very wide range of systems (including your favorite programming languages).
  • Note: 2013-05-09 06:00:00 in the samples is not ISO 8601, but 2013-05-09T06:00:00 is (simple change - just add a "T" instead of a space - these values will be computer-generated anyway).
• Please recommend MIME types for the values of format. Otherwise, you'll end up with all kinds of variations for the same format: "JSON", "json", "JavaScript Object Notation", etc. MIME is super well-supported. Note that DCAT recommends dcat:mediaType for MIME types.
  • see Revise 'format' to use MIME type #117
• Recommend that license be a link to the license.

Other comments:

• Dublin Core has a richer representation for spatial which you may want to consider.
• dcterms:rights is more popularly implemented than dcterms:license, and DCAT is considering switching to it after feedback from the community. rights is also semantically broader than license. license isn't incorrect in your use case - but it's the less common option.

JSON errors:

• The example files use frequency instead of accrualPeriodicity
  • fixed Have the examples match the schema re: use of accrualPeriodicity #58
• dataQuality should be a boolean (true), not a string ("true")
  • fixed dataQuality should be encoded as a boolean in JSON, not a string #56

[jpmckinney]

FYI, DCAT is transitioning to Candidate Recommendation (CR) at W3C - most of the changes to DCAT mentioned above happened over the last year before this repository was published. contactPoint is being added in response to Last Call feedback (the stage before CR in the standardization process). Just assuring you that DCAT will not continue to change in significant ways and that it is very nearly final at this point.

Also, I don't mind writing pull requests for these; I figure it's best to discuss first.

[benbalter]

👍 for dropping granularity, implemented in #115

[MarinaNitze]

Thanks for all of your hard work on this!

• A group discussion nixed changing person to contactPoint. If you think this was wrong, please re-submit a new issue just for this item for broader discussion.
• Keeping mbox but appreciate the note. If there are places where we should make that clearer, please point them out.
• Temporal has ISO 8601-compliant, solidus-delimited start/end datetime range as of Proposed Final Metadata Schema 1.0 #44.
• dataDictionary is optional
• Feed is removed as of Proposed Final Metadata Schema 1.0 #44. WebService is still in discussion in webService #37.
• Arrays are in place as of Proposed Final Metadata Schema 1.0 #44.
• All date fields are now ISO 8601 of least resolution.
• Format now calls for MIME types as of Proposed Final Metadata Schema 1.0 #44

I think that closes out any outstanding issues here. Thanks again!