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

Blank node as predicate tests #550

Open
gkellogg opened this issue Oct 11, 2022 · 4 comments
Open

Blank node as predicate tests #550

gkellogg opened this issue Oct 11, 2022 · 4 comments

Comments

@gkellogg
Copy link
Member

From digitalbazaar/jsonld.js#498.

cc/ @pchampin @davidlehn

(the same issue is present in PyLD: digitalbazaar/pyld#167)

Consider the following:

{
  "@context": {
    "t": "_:b"
  },
  "@type": "t:x"
}

It expands to

[
  {
    "@type": [
      "t:x"
    ]
  }
]

while it should expand to

[
  {
    "@type": [
      "_:bx"
    ]
  }
]

Indeed, step 14.2.5 of Create Term Definition clearly states:

If term contains neither a colon (:) nor a slash (/), simple term is true, and if the IRI mapping of definition is either an IRI ending with a gen-delim character, or a blank node identifier, set the prefix flag in definition to true.

(emphasis is mine)

Therefore, step 6.4 of IRI Expansion should apply.

@gkellogg
Copy link
Member Author

These should probably use the json-ld-1.0 processing mode, although the treatment in 1.1 would be the same. However, blank nodes as predicates is obsolete in 1.1 (from definition of property).

@pchampin
Copy link
Contributor

Actually, expand test 0038 does test this (this is how I ran into this problem, actually), and it is marked with specVersion 1.0.
Note however that the problem occurs even when blank nodes are used in object position (as in my minimal example), so a 1.1. version of 0038, where bnode as predicate are excluded, should probably be added.

@davidlehn
Copy link
Contributor

Ah, I see. jsonld.js, and probably pyld, skip running 1.0 tests these days, so such behavior was not noticed. Perhaps the task here is to add a expand 0038 derived test with expected 1.1 processor results.

@gkellogg
Copy link
Member Author

I suppose we could just change the processing mode on these tests, as it's still expected behavior of 1.1 systems, even though it's considered obsolete. That may be better than simply duplicating the tests for 1.1 mode.

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

No branches or pull requests

3 participants