Problem validating JSON-LD @ nodes like @id

[cueckoo]

Originally opened by @fils in cuelang/cue#691

Thanks @mpvl for pointing me here..

I've new to cue so still having trouble understanding the following.

Running:

cue vet -c minimal.json testing.cue

min: 2 errors in empty disjunction:
min: conflicting values "test" and 0 (mismatched types string and int):
    ./minimal.json:12:10
    ./testing.cue:8:7
min: conflicting values "test" and number (mismatched types string and number):
    ./minimal.json:12:10
    ./testing.cue:8:11

I feel stupid asking.. but I simply have not been able to find how to declare that @id must be present.
Sorry for the noob question.

The inputs are

testing.cue

#Context: {
	"@vocab":  "https://schema.org/" 
}
"@context": #Context

"@id": string   // must have an @id value node
min: *0 | number    // 0 if undefined
max: number & >min  // must be strictly greater than min if defined.

minimal.json

{
  "@context": {
    "@vocab": "https://schema.org/"
  },
  "@type": "Dataset",
  "name": "Removal of organic carbon by natural bacterioplankton communities as a function of pCO2 from laboratory experiments between 2012 and 2016",
  "description": "This dataset includes results of laboratory experiments ",
  "url": "https://www.example-data-repository.org/dataset/472032",
  "version": "2013-11-21",
  "keywords": ["ocean acidification", "OA", "Dissolved Organic Carbon", "DOC", "bacterioplankton respiration", "pCO2", "carbon dioxide", "elevated pCO2", "oceans"],
  "license": "CC-BY-4.0",
  "min": "test"
}

[cueckoo]

Original reply by @mpvl in cuelang/cue#691 (comment)

You did the right thing. The error that you are getting means that there was no concrete value and thus a required field is missing, thereby implying a required field is missing.

We are seriously contemplating adding a ! marker for fields so you could write:

"@id"!: string   // must have an @id value node (PROPOSAL)

making it explicit that a field is required. This should make the corresponding error message also clearer. One benefit is that required fields are typically rarer in API, so ! should not have to be used too much. In addition, it results in a somewhat better model that was we currently have with ?. For one, we would have better error messages. :)

The transition would be fairly straightforward, as ? and unmarked fields would pretty much retain their meaning. If approved, we plan to introduce this after the v0.3.0 release.

[cueckoo]

Original reply by @mpvl in cuelang/cue#691 (comment)

Ah, okay. I see your point. This is a validation issue, potentially. cue vet validates in multiple stages. It checks for evaluation errors (invalid CUE) and only then checks for concreteness. If you remove the offending min field, the resulting error it will show will be:

$ eval -c testing.cue minimal.json
"@id": incomplete value string
max: incomplete value >0

But arguably it should show all these errors at once. Feel free to file a feature request or bug report.

[cueckoo]

Original reply by @fils in cuelang/cue#691 (comment)

I follow now. Yeah, it would be great for things like schema.org JSON-LD validation (my use case) to be able to get both validation/evaluation of present items, but also concreteness.

I can make this work for now since if there are errors in the data graph, then it needs to be checked anyway and once those are resolved, another vet run would raise any concreteness issues, if any. I can appreciate that is might be hard to check for concreteness in a graph that already has evaluation errors. Still, if possible, it would be nice to be able to report as many errors to users on the first pass.

I'm already more excited for using this in JSON-LD valdiation than SHACL. :)

appreciate the help! and thanks for being on Go Time! It's how I found this project...
Thank you..