Browser validator: Unclear error "no dataset description found"

[pederisager]

For two separate datasets I receive this error:

What does this error mean? The directories I submitted both have a file called "dataset_description.json" contained in the first layer of the directory, and this JSON file contains a " description" field.

In general I think novice users would find it very helpful if returned errors also included some indication of what the user should do to fix the problem.

Here is the content of "dataset_description.json" for one of the submitted projects:
{ "@type": "Dataset", "@context": "https://schema.org/", "name": "Red Square Meta-Data", "description": "This repository contains tables extracted from a large number of meta-analyses published in the journal Psychological Bulletin (ISSN: 0033-2909), as well as associated materials and analyses.", "schemaVersion": "0.1.0", "license": "", "author/creator": [ "Jochem Bek", "Remy Hertog", "Peder Mortvedt Isager", "Daniel Lakens", "Maximilian Maier", "Pepijn Obels" ], "citation": "", "funder": "", "url": "", "sameAs": "", "variableMeasured": [ { "@type": "PropertyValue", "name": "x_study", "description": "Author and publication year reference" }, { "@type": "PropertyValue", "name": "x_authors" }, { "@type": "PropertyValue", "name": "x_study_year" }, { "@type": "PropertyValue", "name": "x_study_description" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, { "@type": "PropertyValue", "name": "" }, ], "keywords": [ "meta-data", "meta-analysis", "Psychological Bulletin", "psychology", "database" ], "temporalCoverage": "", "spatialCoverage": "", "datePublished": "", "dateCreated": "2019-03-01", }

[FelixHenninger]

Hi @pederisager , and many thanks for your report -- this is very clearly a bug 🐛 , so let's track it down! Is there any way you could make a reproducible example from your dataset, for example by creating a zip file of the folder you're submitting for validation? That would be enourmously helpful.

Thanks again for taking the time for testing and reporting this issue! 😍 Best,

-Felix

[pederisager]

My pleasure, thank you for tracking it down!

You should be able to reproduce the error with the zipped dir attached.

validator_bug_test.zip

[FelixHenninger]

Hej @pederisager, thanks a lot! Your example looks a-ok (there are some trailing commas in the JSON at lines 225 and 237), so this is indeed a validator issue -- can you help my test a hypothesis/wild guess? My hunch is this one: Could it be that you're selecting the files by clicking on the validator 'button' and then selecting the folder? If so, does the output make more sense if you drag-and-drop the folder?

If I'm correct, this is my mistake, and a purely UI-level issue: The file selector passes the files to the validator in a different format than the drag-and-drop interface, and it's tricky to correct for that. For the time being, I thought I had removed the 'click to select' message, but apparently I haven't. I'm gonna do that until we figure out how to make the two file input modes equivalent.

Hope that makes sense -- have a great weekend!

[pederisager]

The issue is not resolved by drag-and-drop, but I get a different issue message for the same file:

If I fix the trailing comma issue you spotted, I get yet another error message for the same file after drag-and-drop (click method yields the same "no data description found" issue as before):

[FelixHenninger]

Hi Peder,

I'm glad to hear that things work via drag-and-drop! The last two issues you've found are the validator working as it should: Out-of-the box, the JSON is indeed invalid, and with the file format fixed, the schema doesn't match our expectations. For example:

• The funder is a string in your metadata, but the Psych-DS spec expects a list, and schema.org requires an entry of the type Person or Organization
• Similarly, URL is defined as a list in Psych-DS.
• There is an ongoing discussion about the format of temporalCoverage, but right now we follow the Psych-DS example of requiring a 2019-06-05/2019-09-21 format.
• The same for datePublished, which is an empty string in the dataset, but should be something like 2019-09-21.

From my perspective, these are all issues where the spec is underdefined and/or I'm misunderstanding it. I suggest we move this discussion over to the spec document?

Thanks again for your feedback, and kind regards,

-Felix

[pederisager]

Great! I resolved all the issues identified by the validator and then it gives the dataset a "looks great!"

One comment: funder datePublished url and temporalCoverage are all optional/recommended fields. If I delete these fields from the JSON the validator apparently doesn't complain. Instead of deleting them from the JSON however i just want to leave them as empty strings temporarily, so that I'll remember to fill them in when the info is available. Could the validator treat empty strings as if the field was not specified? That would be extremely convenient given that I mostly want to copy a template dataset_description.json from somewhere (that has all possible fields contained within it) and fill it in with info relevant to my data as I go.

[nicebread]

From a user's perspective, I'd second the wish to have empty templates which can be filled out later (and still be valid). But maybe null instead of empty string? Probably depends on the meaning we want to carry.

[FelixHenninger]

I see you both, but I also think that this is a spec issue and discussion should move to the spec document. Would either of you be a champion for this and also for the null proposal in issue #5?

The way things are right now stems from the fact that -- as you noticed (and as we discussed over in #5) -- JSON schemas require any present value to match the pattern. We can change this to allow empty values or null.

Personally I think that the role of a validator (as [ideally] a final arbiter of the spec) should be to alert users to any possible mistake that would result in a parsing error, even if the intention is to fill out values later. We could think about a lenient or template mode which ignores empty strings or the like, but in my view the effort would be better spent working together on the metadata builder tools. But that's just my two cents, again I think that this is a community choice to be made on the spec side.

[mekline]

(I brought this up on #5, but for tracking purposes: I agree that null/blank properties would be useful to the community, and happy for us to discuss it, but let's attempt to do whatever Schema.org Dataset expects first off? And then determine what decisions remain from there)

[pederisager]

Agree @FelixHenninger, I had not considered the downsides of having null be an allowed value for the pattern match. You probably have a much better understanding of the nuts and bolts of this than I do so do take any suggestions with a healthy grain of salt. All I can say is that, as a user, it is confusing that the validator fails for an empty field that is specified as "optional" in the spec document. The fact that I can just delete this field to solve the issue is not obvious, since the validation will also sometimes also fail if I delete (required) fields. Some documentation is probably sufficient to resolve this.

[FelixHenninger]

as a user, it is confusing that the validator fails for an empty field that is specified as "optional" in the spec document.

Ah, I think see now, thanks! (sorry, I was being thick, and didn't get this earlier). Would it, from your perspective, be useful for example to change the message text to "Optional field funder should be array" in the last screenshot above?

You probably have a much better understanding of the nuts and bolts of this [...]

Hell no! Making this up as I go along 😁. Super-glad to have you with us, and to figure this out together!

[pederisager]

Would it, from your perspective, be useful for example to change the message text to "Optional field funder should be array" in the last screenshot above?

Yes, although I would prefer it to be even more specific. Something like "Optional field funder should be array if specified, or be deleted if the intention is to leave it unspecified". Otherwise I'm not sure it is cler to the user what they should do if they want to leave the field unspecified.

[mekline]

I like the idea of the validator (where possible) referencing specific fields or files that are causing trouble. (A more general issue: in many cases, users will get a ton of errors to start out, for instance if 20 files all are slightly wrong in the same way - we'll want to eventually think about overwhelm and readability for these lists, probably more of an issue for the validator than the R tools.)

…

On Mon, Sep 23, 2019 at 8:07 AM Peder Mortvedt Isager < ***@***.***> wrote: Would it, from your perspective, be useful for example to change the message text to "Optional field funder should be array" in the last screenshot above? Yes, although I would prefer it to be even more specific. Something like " *Optional* field funder should be array if specified, or be deleted if the intention is to leave it unspecified". Otherwise I'm not sure it is cler to the user what they should do if they want to leave the field unspecified. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUA75JI3CSPMCQNHF6NJTTQLCWOJANCNFSM4IXNK55Q> .