Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add graph container array tests. #585

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

davidlehn
Copy link
Contributor

  • Add tests for @graph @container with and without nullified context with an array of plain literals.
  • Add tests for @graph @id @container with and without nullified context with an array of IRIs.

The expand/toRdf parallel testing and number is a bit confusing. Not all the tests have a twin. I jumped up to 0200 thinking maybe going forward from there new tests might align better.

As of now, different implementations have different results for these sorts of tests. For instance, for 0203:

  • jsonld.js - n-quads drops the data, triggers a "safe mode" error for canonizing due to the drops. (link)
  • RDF Distiller - errors with "undefined method `[]' for nil:NilClass" (link)
  • Sophia - n-quads has data with blank node ids - (link)

People have been looking at this construct in places like the VC work. Providing URLs in the verifiableCredential property of a VP (I think). This additional coverage is needed to understand what should happen here unless this is specifically undefined behavior. (I'm not sure if some tests duplicate other tests, added variations for clarity.)

I'm not sure what the output should be of these tests. Currently it has the jsonld.js empty output, but that may not be correct in all cases?

What other variations of these tests should be added?

Also related is what to do with a "@container": ["@graph", "@id"] with only a IRI provided instead of a mapping. I'm not sure that has test either. It outputs <ex:outer> <ex:p> <ex:test> ./... "ex:test" triples in jsonld.js and others, which seems closer to the behavior people might expect without the @id, but the feature was designed for only mappings instead of values like this?

- Add tests for `@graph` `@container` with and without nullified context
  with an array of plain literals.
- Add tests for `@graph` `@id` `@container` with and without nullified
  context with an array of IRIs.
@gkellogg
Copy link
Member

gkellogg commented Feb 7, 2024

The implication in the Expand Algorithm step 13.12.1 is that if must either be a node object or a graph object, and not a value object. I agree that if it is a value object, should be omitted. However, I do get an expanded output after accounting for this:

[
  {
    "@id": "ex:outer",
    "ex:p": []
  }
]

I don't know of a step in the expansion algorithm which would eliminate this entry.

It did require a change in 13.12.1 to eliminate expanded values which are not either node objects or graph objects if container includes @graph. We may need an Erratum and issue to add wording to this effect.

Copy link
Member

@gkellogg gkellogg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I noted, I think the expansion results should be different, although it does not change the RDF results.

@gkellogg gkellogg requested a review from pchampin February 7, 2024 21:08
@gkellogg
Copy link
Member

gkellogg commented Mar 6, 2024

This issue was discussed in a meeting.

#585 -> Pull Request 585 Add graph container array tests. (by davidlehn) [test:missing-coverage]
David I. Lehn: Do we have other tests that have a property expanding to an empty array.
... It doesn't change the N-Quads output, but there may be some ambiguity on the expected results.
Gregg Kellogg: It might be a warning condition if the result contains a property with no values.

Copy link
Contributor

@pchampin pchampin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late review.

If we are to make a significant change to the spec for handling this corner case (which, IIUC, would be required to justify these test results), I think I would rather lean towards raising an error on these input.

@gkellogg
Copy link
Member

gkellogg commented Apr 8, 2024

If we are to make a significant change to the spec for handling this corner case (which, IIUC, would be required to justify these test results), I think I would rather lean towards raising an error on these input.

The way we've handled other such issues is to create an erratum and note it as a substantive change. Our charter allows us to address errata, which IMO would include this. Tests are appropriate once the erratum is accepted and changes have been added to the draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

3 participants