You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 18, 2024. It is now read-only.
It's a matter of style, but I'd add a carriage return in the 1st paragraph at "Metadata can range."
Missing "also" in "not only field names, but how information is encoded" at the end of that paragraph
What to Document -- Datasets and Web APIs
1st paragraph: above, series always contain the Oxford comma. For consistency's sake, I'd add a comma before "or temporal" in the parentheses in the first sentence
In contrast, there's no need for the comma after "(e.g., a CSV)"
Metadata File Format -- JSON
Oxford comma in "read, parse, and generate" for consistency's sake
No need for the semicolon after "(1) a collection of name/value pairs"
Missing verb in "links to downloadable examples." I recommend "you can find links to . . ."
Schema Version Declaration
Might want to experiment with bullet points here: you must do this; you may also do that -- more for the people we'll have to share this information with than for the people putting the json files together
"Common Core" Required Fields
I think it's time to ditch the quotation marks around "common core" everywhere
Is there any reason there's no link to the Further Metadata Field Guidance section?
More nitpicking for consistency's sake: sometimes the definitions in the tables have periods and sometimes they don't. I don't think they're necessary, but I also don't care and doubt anyone else will -- just be consistent
No need to capitalized "data" in the definition of accessLevel (3x)
"Common Core" Required-if-Applicable Fields
license: definition: missing comma after "i.e."
At v. 1.1 meeting a while back, I mentioned that I spend a lot of time trying to get 300ish characters down to 255 for accessLevelComment, i.e., rights. I take it the decision was to stick to 255 to prevent essays?
Beyond Common Core -- Extending the Schema
There's something off about the first sentence. Try this? "Extensional" and/or domain-specific metadata FIELDS can easily be added using other vocabularies even if the field is not a term . . .
Expanded Fields
More obsession with consistency: missing "the" in "frequency with which dataset is published" (it's common to leave out "the" and similar words in tables, but they appear throughout these tables)
Ditch the capitalization of "dataset" in the description of landingPage; consider linking to data.gov
systemOfRecords description: "systems" should be singular
...from the catalog fields:
Usage note: same period/no period question
accessLevel notes: missing "the" in "this field refers to the degree to which"
Nice! "For example, if a member of the public can walk into your agency and obtain a dataset." Another example I use is "if you would release it in its entirety under the FOIA, it's public; if you'd redact and release, it's restricted public."
The text was updated successfully, but these errors were encountered:
per #378 -
* removing unnecessary semi-colon
* adding a missing verb
* making punctuation in definitions consistent (added periods)
* Adding 'the' to frequency sentence
* systems -> system
* adding missing 'the' to accessLevel notes
Standard Metadata Vocabulary
It's a matter of style, but I'd add a carriage return in the 1st paragraph at "Metadata can range."Missing "also" in "not only field names, but how information is encoded" at the end of that paragraphWhat to Document -- Datasets and Web APIs
1st paragraph: above, series always contain the Oxford comma. For consistency's sake, I'd add a comma before "or temporal" in the parentheses in the first sentenceIn contrast, there's no need for the comma after "(e.g., a CSV)"Metadata File Format -- JSON
Oxford comma in "read, parse, and generate" for consistency's sakeNo need for the semicolon after "(1) a collection of name/value pairs"Missing verb in "links to downloadable examples." I recommend "you can find links to . . ."Schema Version Declaration
"Common Core" Required Fields
I think it's time to ditch the quotation marks around "common core" everywhereMore nitpicking for consistency's sake: sometimes the definitions in the tables have periods and sometimes they don't. I don't think they're necessary, but I also don't care and doubt anyone else will -- just be consistentNo need to capitalized "data" in the definition of accessLevel (3x)"Common Core" Required-if-Applicable Fields
Beyond Common Core -- Extending the Schema
There's something off about the first sentence. Try this? "Extensional" and/or domain-specific metadata FIELDS can easily be added using other vocabularies even if the field is not a term . . .Expanded Fields
More obsession with consistency: missing "the" in "frequency with which dataset is published" (it's common to leave out "the" and similar words in tables, but they appear throughout these tables)Ditch the capitalization of "dataset" in the description of landingPage; consider linking to data.govsystemOfRecords description: "systems" should be singular...from the catalog fields:
Usage note: same period/no period questionaccessLevel notes: missing "the" in "this field refers to the degree to which"The text was updated successfully, but these errors were encountered: