keyword element: string or array?

[mhogeweg]

The use of the keyword element is described as "Separate keywords with commas". however, the cardinality is set to (1,n).

is the intent to have 1 keyword element with a string of comma separated keywords (as in the example in schema.md)

{"keyword":"squash,vegetables,veggies,greens,leafy,spinach,kale,nutrition,tomatoes,tomatos"}

or have 1 keyword element with an array of keywords?

{"keyword": ["squash","vegetables","veggies","greens","leafy","spinach","kale","nutrition","tomatoes","tomatos"]}

[waldoj]

The example that @mhogeweg is referring to can be found a few tables down from this anchor. This is an important distinction that needs to be made—I'm glad you caught it, Marten!

[mhogeweg]

there are additional suggestions to be made for describing the JSON structure and cardinality. for example webService has cardinality (0,1) with a condition of when the element needs to be populated, however format has a cardinality of (1,n) with a condition of when the element needs to be populated. if format is not always required I'd expect format to then have cardinality (0,n).

regarding accessURL, format, and size, these are part of the distribution element. does the cardinality for these elements apply to a single distribution element? or to the overall JSON structure?

[kachok]

@mhogeweg there is another issue in GitHub on accessURL vs distribution element in JSON and which one should be used for multiple datasets.

[jpmckinney]

Indeed, arrays should be preferred to comma-delimited values, see #39

[skybristol]

+1 on this issue and #39 for sure. Comma-delimited lists - bad...

It would be very good to see the documentation and examples changed accordingly if we're going this route.

[seanherron]

@skybristol Agree. I had been submitting requests with comma-deliminated 1,n values since that had been the predominate style beforehand, but altering this to an array would be preferable. The only issue I could see is that agencies are already building and releasing data.json files (and many tools have been built to help with that), and we don't want to change things around too drastically and break backwards compatibility.

[mhogeweg]

now is the time to make some key changes if they are needed. there are still various questions on the proposed structure. yes, agencies and vendors are working on tools and that doesn't mean you can't make any change. at some point the spec would be labeled (v1.0 or such) and then that version is frozen, but the spec may develop further. this is an effect of coming out with a spec... regardless of being a formal standard or community standard.

[seanherron]

@mhogeweg agree, but we also have a deadline of November 9th for agencies to publish a ton of data in line with this spec, so I'm not sure if we have as ideal of a development process as we would like.

[jpmckinney]

Hmm, the project may want to stop saying that it is implementing DCAT if these sorts of changes (including #49 and #57) aren't going to me made. The linked issues address inconsistencies and errors in this project's implementation of DCAT.

[benbalter]

👍 for an array of keywords

[MarinaNitze]

The keyword field has been (a) renamed to "keywords" and (b) changed to an array of comma-separated strings in the proposed 1.0 final metadata schema. See #44. Thanks everyone!