json-ld-api

json-ld-api copied to clipboard

Rules for dropping free-floating values in Expansion Algorithm

[{"_id":"636d442da63f0c535f5d7c18","body":"This should be read as if the result contains `@value` or `@list`, as it could indeed have both `@value` and `@type` or `@language`, and could also have `@index`.\r\n\r\nThis could be considered an erratum for 1.1.","issue_id":1667064560148,"origin_id":644409879,"user_origin_id":46296,"create_time":1592257995,"update_time":1592258012,"id":1668105261855,"updated_at":"2022-11-10T18:34:21.855000Z","created_at":"2022-11-10T18:34:21.855000Z"},{"_id":"636d442da63f0c535f5d7c19","body":"Summary:\r\n\r\nStep 19.1 of the [Expansion Algorithm](https:\/\/www.w3.org\/TR\/json-ld11-api\/#algorithm-3) should be changed to the following:\r\n\r\n> 19.1) If result is a [map](https:\/\/infra.spec.whatwg.org\/#ordered-map) which is empty, or contains only the [entries](https:\/\/infra.spec.whatwg.org\/#map-entry) `@value` or `@list` ***(with the possible addition of `@type`, `@language`, or `@index`, as appropriate)*** set result to `null`.","issue_id":1667064560148,"origin_id":1280053987,"user_origin_id":46296,"create_time":1665953121,"update_time":1665953468,"id":1668105261858,"updated_at":"2022-11-10T18:34:21.858000Z","created_at":"2022-11-10T18:34:21.858000Z"},{"_id":"636d442da63f0c535f5d7c1a","body":"@pchampin It's questionable if this is really a normative change, as we've long held that the test results are what matters, and they remain unchanged. If considered editorial, we can actually update the ED.","issue_id":1667064560148,"origin_id":1280054575,"user_origin_id":46296,"create_time":1665953339,"update_time":1665953339,"id":1668105261861,"updated_at":"2022-11-10T18:34:21.860000Z","created_at":"2022-11-10T18:34:21.860000Z"},{"_id":"636d442da63f0c535f5d7c1b","body":"@gkellogg agreed","issue_id":1667064560148,"origin_id":1283098361,"user_origin_id":304612,"create_time":1666133301,"update_time":1666133301,"id":1668105261865,"updated_at":"2022-11-10T18:34:21.865000Z","created_at":"2022-11-10T18:34:21.865000Z"},{"_id":"636d442da63f0c535f5d7c1c","body":"@pchampin This came up in https:\/\/github.com\/w3c\/json-ld-api\/issues\/518#issuecomment-748567302 where @iherman made the case that such changes are, indeed, normative. I'll keep it as is.","issue_id":1667064560148,"origin_id":1283101710,"user_origin_id":46296,"create_time":1666133603,"update_time":1666133603,"id":1668105261868,"updated_at":"2022-11-10T18:34:21.868000Z","created_at":"2022-11-10T18:34:21.868000Z"}]

The wording of step 19.1 is: > If result is a map which is empty, or contains only the entries `@value` or `@list`, set result to null. That *only* indicates...

kal

What to do with value entries outside value objects?

[{"_id":"636d48ccb928086c816f3e53","body":"I consider this as an oversight; this section should have been updated when we added the `@direction` keyword. @gkellogg @dlongley WDYT?\r\n\r\nAlso, it seems that we have no test case for step 18 (the one quoted by @timothee-haudebourg). The proposed snippet is a good candidate for such a test.","issue_id":1667064560152,"origin_id":952786268,"user_origin_id":304612,"create_time":1635331358,"update_time":1635331358,"id":1668106444121,"updated_at":"2022-11-10T18:54:04.120000Z","created_at":"2022-11-10T18:54:04.120000Z"}]

In my current implementation of the expansion algorithm, when the expanded node only contains value entries (i.e. `@language` or `@direction` entries), then it is dropped. In my interpretation of the...

timothee-haudebourg

Invalid '@base' IRI is accepted by the context processing algorithm in deserialization test suite.

[{"_id":"636d5164e5647053728364bf","body":"The IRI validation for output is actually done in the toRdf algorithm, and this is exclusively a toRdf test (https:\/\/w3c.github.io\/json-ld-api\/tests\/toRdf-manifest.html#tli12). If you were to just run the expansion algorithm on the input, I would expect the following result:\r\n\r\n```json\r\n[{\r\n \"foo:bar\": [{\r\n \"@list\": [{\r\n \"@id\": \"http:\/\/invalid\/<>\/test\"\r\n }]\r\n }]\r\n}]\r\n```\r\n\r\nStep on of the [Object to RDF Conversion algorithm](https:\/\/www.w3.org\/TR\/json-ld11-api\/#algorithm-13) says to return `null` if the value of `@id` is not a valid IRI. This is what effectively results in an empty list.\r\n\r\nIt's not unreasonable for you to bail out at 5.7.3 in the context processing algorithm, as it specifically says if it is an IRI, and this is arguably not an IRI, as it is not valid, but other discussions of IRIs in the algorithms do distinguish between IRIs and valid IRIs, and this does not specifically call for IRI validation.","issue_id":1667064560157,"origin_id":906726725,"user_origin_id":46296,"create_time":1630010307,"update_time":1630010307,"id":1668108644551,"updated_at":"2022-11-10T19:30:44.551000Z","created_at":"2022-11-10T19:30:44.551000Z"},{"_id":"636d5164e5647053728364c0","body":"I see, however I am not very comfortable with the blurry concept of an \"invalid IRI\". Something is or is not an IRI, and since my implementation is statically typed, this allows me to use a dedicated IRI type that provides many advantages for the users. This means that every time there is a condition of the form \"If x is an IRI\" I will try to parse `x` into an IRI using [RFC3987](https:\/\/datatracker.ietf.org\/doc\/html\/rfc3987), validating it on the way.\r\n\r\nIn #517 caused by another invalid IRI, you said\r\n> it would be better if the examples used valid IRIs\r\n\r\nI agree with that, at least when the JSON-LD syntax specification requires IRI\/IRI references. The concept of \"invalid IRIs\" (I also read \"well-formed IRI\") seems to exist only in the \"Processing Algorithms and API\" document. The [syntax specification of context definitions](https:\/\/w3c.github.io\/json-ld-syntax\/#context-definitions) is pretty clear:\r\n> If the context definition has an `@base` key, its value **MUST be an IRI reference**, or null.\r\n\r\nwhere \"IRI reference\" directly links to [RFC3987](https:\/\/datatracker.ietf.org\/doc\/html\/rfc3987). This contrasts with keys in node objects that can, as far as I understand, take any string value (where I was in the past wrongly expecting an IRI):\r\n> Keys in a node object that are not keywords **MAY expand to an IRI** using the active context. \r\n","issue_id":1667064560157,"origin_id":915539274,"user_origin_id":14182174,"create_time":1631132163,"update_time":1631132163,"id":1668108644556,"updated_at":"2022-11-10T19:30:44.555000Z","created_at":"2022-11-10T19:30:44.555000Z"},{"_id":"636d5164e5647053728364c1","body":"I'm not sure why you find \"invalid IRI\" a blurry concept, as RFC3987 describes the ABNF to validate an IRI (\"well-formed IRI\" might be considered a synonym). But, this has to take into consider the resolution protocol, so that an IRI reference may be turned into an IRI, which is a necessary part of validation. You might say that an invalid IRI is not an IRI, by definition, which is strictly correct. But data is full of things that look like IRIs but end up failing validation.\r\n\r\n> If the context definition has an `@base` key, its value MUST be an IRI reference, or null.\r\n\r\nFrom this you could infer that the API MUST validate everything treated as an IRI and take appropriate action if it is not. As I mentioned, this is entirely reasonable, but might have consequences for existing implementations. It might rise to the point of requiring an Edited Recommendation, after going through the appropriate processes to correct. Certainly, the first step would be a PR that addressed the algorithms and affected test results, which would be necessary to consider further action. It would be great if you were to put something like this together. Even if we don't actually try to go through the process, getting it in the Editor's Draft would be a good start.\r\n\r\n> Keys in a node object that are not keywords MAY expand to an IRI using the active context.\r\n\r\nYes, this is to deal specifically with the need for being able to process _any_ JSON data, and ignore keys that don't expand to IRIs, so it's specifically _not_ an error for keys to not expand to IRIs (or blank nodes, oddly).","issue_id":1667064560157,"origin_id":915556257,"user_origin_id":46296,"create_time":1631133790,"update_time":1631133790,"id":1668108644559,"updated_at":"2022-11-10T19:30:44.558000Z","created_at":"2022-11-10T19:30:44.558000Z"},{"_id":"636d5164e5647053728364c2","body":"Maybe I should say \"not formally defined\" instead of \"blurry\". I don't have a strong opinion on whether or not the described API should validate everything. Giving some wiggle room to implementations is not necessarily a bad idea. However I think the tests should strictly follow the syntax specification and not assume that all the implementations will inevitably use the wiggle room they are given. My implementation tries to precisely follow the syntax specification, which means that in this particular test case, the `@base` IRI will be rejected, whereas the test is written in a way that assumes a loose interpretation of the specification that accepts it.","issue_id":1667064560157,"origin_id":915574456,"user_origin_id":14182174,"create_time":1631135474,"update_time":1631135498,"id":1668108644561,"updated_at":"2022-11-10T19:30:44.561000Z","created_at":"2022-11-10T19:30:44.561000Z"},{"_id":"636d5164e5647053728364c3","body":"If you could do a PR with some specific test changes, it would help. We can evaluate the potential algorithmic changes once that is settled.","issue_id":1667064560157,"origin_id":916420298,"user_origin_id":46296,"create_time":1631219954,"update_time":1631219954,"id":1668108644564,"updated_at":"2022-11-10T19:30:44.563000Z","created_at":"2022-11-10T19:30:44.563000Z"}]

From the step 5.7 of the context processing algorithm it is clear that a `@base` value is accepted iff it is `null` (step 5.7.2) or an IRI (5.7.3) or a...

timothee-haudebourg

Possible mistake in Context Processing Algorithm

[{"_id":"636d48ee1e434437e73dc7cb","body":"(I believe 5.1.1 is the step you meant).\r\n\r\nI think 5.1.1 should check _result_ instead of _active context_, so the paragraph could read as follows:\r\n\r\n| If _override protected_ is `false` and _result_ contains any *protected term definitions*, an `invalid context nullification` has been detected and processing is aborted.\r\n\r\ncc\/ @dlongley @pchampin ","issue_id":1667064560160,"origin_id":748520234,"user_origin_id":46296,"create_time":1608409179,"update_time":1608409179,"id":1668106478416,"updated_at":"2022-11-10T18:54:38.415000Z","created_at":"2022-11-10T18:54:38.415000Z"},{"_id":"636d48ee1e434437e73dc7cc","body":"@iherman Should this be marked as Editorial, given our general policy about tests winning out over algorithm text?","issue_id":1667064560160,"origin_id":748520568,"user_origin_id":46296,"create_time":1608409371,"update_time":1608409371,"id":1668106478419,"updated_at":"2022-11-10T18:54:38.419000Z","created_at":"2022-11-10T18:54:38.419000Z"},{"_id":"636d48ee1e434437e73dc7cd","body":"I imagine the next step (5.1.2) may need to talk about setting `result` back to an initial active context instead of saying it's being initialized as well. I do think it's clearly a typo\/editorial.","issue_id":1667064560160,"origin_id":748539912,"user_origin_id":168137,"create_time":1608420961,"update_time":1608420961,"id":1668106478423,"updated_at":"2022-11-10T18:54:38.422000Z","created_at":"2022-11-10T18:54:38.422000Z"},{"_id":"636d48ee1e434437e73dc7ce","body":"> @iherman Should this be marked as Editorial, given our general policy about tests winning out over algorithm text?\r\n\r\nI do not think so. If my understanding is correct, the normative description of the algorithm changes, which may, potentially, affect other implementations (even though the change is not far-reaching).","issue_id":1667064560160,"origin_id":748567302,"user_origin_id":520723,"create_time":1608443284,"update_time":1608443284,"id":1668106478426,"updated_at":"2022-11-10T18:54:38.426000Z","created_at":"2022-11-10T18:54:38.426000Z"},{"_id":"636d48ee1e434437e73dc7cf","body":"Summary:\r\n\r\nUpdate the [Context Processing Algorithm](https:\/\/www.w3.org\/TR\/json-ld11-api\/#algorithm) steps 5.1.1 and 5.1.2 to look for protected term definitions in _result_ not _active context_ and to initialize _result_ to an initial active context as follows:\r\n\r\n> 5.1.1) If _override protected_ is `false` and _result_ contains any [protected](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dfn-protected) [term definitions](https:\/\/www.w3.org\/TR\/json-ld11\/#dfn-term-definition), an [invalid context nullification](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dom-jsonlderrorcode-invalid-context-nullification) has been detected and processing is aborted.\r\n> 5.1.2) Set _result_ as a new initial [active context](https:\/\/www.w3.org\/TR\/json-ld11\/#dfn-active-context) as defined above, and setting both [base IRI](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dfn-context-base-iri) and [original base URL](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dfn-original-base-url) to the value of [original base URL](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dfn-original-base-url) in _active context_, and, if _propagate_ is `false`, [previous context](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dfn-previous-context) in _result_ to the previous value of _result_.\r\n\r\n","issue_id":1667064560160,"origin_id":1280068547,"user_origin_id":46296,"create_time":1665958384,"update_time":1665958384,"id":1668106478429,"updated_at":"2022-11-10T18:54:38.429000Z","created_at":"2022-11-10T18:54:38.429000Z"}]

Hi, Step 5.5.1 of the Context Processing Algorithm says: > If `override protected` is false and `active context` contains any protected term definitions, an `invalid context nullification` has been detected...

timothee-haudebourg

Test compact#t0080 is wrong

[{"_id":"636d4329b4ee765e3b0e5a6e","body":"The IRI Compaction algorithm clearly allows the term to be selected:\r\n\r\n> 4.8.) Otherwise, if value is a graph object, prefer a mapping most appropriate for the particular value.\r\n> 4.8.2) If value contains an `@id` entry, append the values `@graph@id` and `@graph@id@set` to containers.\r\n> 4.8.3) Append the values `@graph`, `@graph@set`, and `@set` to containers.\r\n\r\nIt is step 4.8.3 which allows the term to be selected, so the test does not seem too be incorrect based on the algorithm text. We could consider in a future update changing the steps in the algorithm to disallow its selection, but that's not what's there right now.\r\n\r\n> however, the expected compacted result expands to the following dataset:\r\n\r\n> _:b0 <http:\/\/example.org\/input> _:b1 .\r\n> _:b2 <http:\/\/example.org\/value> \"x\" <http:\/\/example.org\/gid> .\r\n\r\nYet this is, indeed, problematic; the result expands to have the value of \"input\" be an anonymous named graph containing a named graph, when that is not called for.\r\n\r\nPerhaps we should consider an erratum to 4.8.3 that makes it an otherwise as well as reconsider other steps in 4.8.","issue_id":1667064560164,"origin_id":713701674,"user_origin_id":46296,"create_time":1603297932,"update_time":1665956083,"id":1668105001276,"updated_at":"2022-11-10T18:30:01.275000Z","created_at":"2022-11-10T18:30:01.275000Z"},{"_id":"636d4329b4ee765e3b0e5a6f","body":"One thing we might consider as an additional step for compaction tests is that they re-expand to their inputs, although there may be some things that make this problematic.","issue_id":1667064560164,"origin_id":713703216,"user_origin_id":46296,"create_time":1603298080,"update_time":1603298080,"id":1668105001278,"updated_at":"2022-11-10T18:30:01.278000Z","created_at":"2022-11-10T18:30:01.278000Z"},{"_id":"636d4329b4ee765e3b0e5a70","body":"> The IRI Compaction algorithm clearly allows the term to be selected:\r\n\r\nYes, I didn't mean to imply that the test was inconsistent with the spec, only that what it did looked wrong (changing the underlying graph). Thanks for spotting which part of the spec was responsible. ","issue_id":1667064560164,"origin_id":713720468,"user_origin_id":304612,"create_time":1603299813,"update_time":1603299813,"id":1668105001281,"updated_at":"2022-11-10T18:30:01.280000Z","created_at":"2022-11-10T18:30:01.280000Z"},{"_id":"66a0ba9bb041d13c3e095f3b","body":"I agree on your expected compaction result (and thus that the test output is wrong). If the input is also flattened -- turning the embedded named graph into a node reference -- it becomes what we expect. So there is a semantic discrepancy here (in the algorithm).","issue_id":1667064560164,"origin_id":1728141563,"user_origin_id":29803,"create_time":1695230219,"update_time":1695230219,"id":1721809563838,"updated_at":"2024-07-24T08:26:03.838000Z","created_at":"2024-07-24T08:26:03.838000Z"}]

The test [compact#t0080] is wrong, IMO. The input (which is in expanded form) corresponds to the following dataset: ``` _:b0 . _:b1 "x" . ``` however, the expected compacted result...

pchampin

integer JSON value should be expanded to an IRI in presence of a base IRI

[{"_id":"636d4f6b1e434437e73dd027","body":"IRI Expansion says nothing about it because, as far as I can tell, it should never be *invoked* with a value that is not as string.\r\n\r\nThe test is usually performed *before* invoking IRI Expansion, raising different error codes depending on the context. E.g.:\r\n\r\n* Create Term Definition, step 14.2.1 https:\/\/www.w3.org\/TR\/json-ld11-api\/#ctd-id-not-null\r\n\r\n* Expansion, step 13.4.3.1 https:\/\/www.w3.org\/TR\/json-ld11-api\/#alg-expand-each-key-value","issue_id":1667064560169,"origin_id":698867260,"user_origin_id":304612,"create_time":1601031781,"update_time":1601031781,"id":1668108139255,"updated_at":"2022-11-10T19:22:19.254000Z","created_at":"2022-11-10T19:22:19.254000Z"},{"_id":"636d4f6b1e434437e73dd028","body":"Indeed, it is forbidden by the specification.\r\n\r\nHowever, I can see no reason for not changing the phase \r\n_is not a string_\r\nwith\r\n_is not a string or integer_\r\nin these steps 13.4.3.1 and 14.2.1 .\r\n\r\nWhat was the reason to exclude integers ?\r\nWas it a bad case of copy and paste in the writing ?\r\nIndeed some cases like language demand strings.\r\n\r\nThis is a frequent case in JSON data id's . And often it is not possible to change one JSON API . \r\n ","issue_id":1667064560169,"origin_id":698888184,"user_origin_id":896281,"create_time":1601035073,"update_time":1601035073,"id":1668108139259,"updated_at":"2022-11-10T19:22:19.259000Z","created_at":"2022-11-10T19:22:19.259000Z"},{"_id":"636d4f6b1e434437e73dd029","body":"> What was the reason to exclude integers ?\r\n> Was it a bad case of copy and paste in the writing ?\r\n> Indeed some cases like language demand strings.\r\n\r\nThis goes back to 1.0, and if you look at RFC3987\/6 URIs\/IRIs are defined based on strings.\r\n\r\nI think it's reasonable to change the expansion algorithm to work over primitive types, which would include string, number and boolean. Note that null is filtered wherever it is seen, so would not be feasible (or useful, IMH). Boolean values aren't too useful either, but better to include for regularity.","issue_id":1667064560169,"origin_id":699038054,"user_origin_id":46296,"create_time":1601052767,"update_time":1601052767,"id":1668108139261,"updated_at":"2022-11-10T19:22:19.261000Z","created_at":"2022-11-10T19:22:19.261000Z"},{"_id":"636d4f6b1e434437e73dd02a","body":"Yes for regularity! Floating point numbers ([included in numbers](https:\/\/tools.ietf.org\/html\/rfc8259#section-6)) also can have usage as `@id` .\r\n\r\nI also looked at [Editor's Draft](https:\/\/w3c.github.io\/json-ld-api) , and reviewed all occurrences of \"not a string\" (14 ! ) .\r\nThere at 13.4.10.1 , I suspect that also the string restriction can be removed. But I don't know enough JSON-LD to tell.\r\n\r\nAnyway, for next step, am I encouraged to make a pull request on https:\/\/github.com\/w3c\/json-ld-api\/pulls\/ ?\r\n","issue_id":1667064560169,"origin_id":699444284,"user_origin_id":896281,"create_time":1601103724,"update_time":1601103724,"id":1668108139264,"updated_at":"2022-11-10T19:22:19.264000Z","created_at":"2022-11-10T19:22:19.264000Z"},{"_id":"636d4f6b1e434437e73dd02b","body":"@jmvanel just an admin comment: at this point, the JSON-LD API is a Recommendation, meaning that it cannot be changed right away without further ado. A PR would be very welcome but, process-wise, what should be done now is to see if it can be listed as a formal Erratum (this is something the CG\/WG has to decide, @gkellogg @BigBlueHat) and, at some point, all these should be collected to issue a new version of the spec.","issue_id":1667064560169,"origin_id":699446365,"user_origin_id":520723,"create_time":1601104423,"update_time":1601104423,"id":1668108139267,"updated_at":"2022-11-10T19:22:19.266000Z","created_at":"2022-11-10T19:22:19.266000Z"},{"_id":"636d4f6b1e434437e73dd02c","body":"> This goes back to 1.0, and if you look at RFC3987\/6 URIs\/IRIs are defined based on strings.\r\n\r\nthe updated recommendation should maybe say that integer and no base URI is an error, but I guess that there is always a base URI (?) .\r\n\r\n \r\n\r\n","issue_id":1667064560169,"origin_id":699468413,"user_origin_id":896281,"create_time":1601112353,"update_time":1601112353,"id":1668108139270,"updated_at":"2022-11-10T19:22:19.269000Z","created_at":"2022-11-10T19:22:19.269000Z"},{"_id":"636d4f6b1e434437e73dd02d","body":"> @jmvanel ... process-wise, what should be done now is to see if it can be listed as a formal Erratum (this is something the CG\/WG has to decide, @gkellogg @BigBlueHat) and, at some point, all these should be collected to issue a new version of the spec.\r\n\r\nYes, an Erratum would be cool; these is none at the moment .\r\n\r\nI see that there no definition of literal in \r\nhttps:\/\/infra.spec.whatwg.org\/#primitive-data-types\r\nbut a link to RDF recommendation for literal should be OK for \"string or number or boolean but not null\" .","issue_id":1667064560169,"origin_id":699486081,"user_origin_id":896281,"create_time":1601121641,"update_time":1601121641,"id":1668108139273,"updated_at":"2022-11-10T19:22:19.273000Z","created_at":"2022-11-10T19:22:19.273000Z"},{"_id":"636d4f6b1e434437e73dd02e","body":"Accepting non-strings as relative IRIs would cause problem when compacting, because it would not be able to round trip. Consider [this example](https:\/\/json-ld.org\/playground\/#startTab=tab-compacted&json-ld=%5B%7B%22%40id%22%3A%22http%3A%2F%2Fexample.org%2Fusers%2F1234%22%2C%22http%3A%2F%2Fschema.org%2Fname%22%3A%5B%7B%22%40value%22%3A%22John%20Doe%22%7D%5D%7D%5D&context=%7B%22%40context%22%3A%7B%22%40base%22%3A%22http%3A%2F%2Fexample.org%2Fusers%2F%22%2C%22%40vocab%22%3A%22http%3A%2F%2Fschema.org%2F%22%7D%7D). How would you decide that the compacted `@id` must be a number rather than a string?\r\n\r\n> I see that there no definition of literal in\r\nhttps:\/\/infra.spec.whatwg.org\/#primitive-data-types\r\nbut a link to RDF recommendation for literal should be OK for \"string or number or boolean but not null\" .\r\n\r\nLiteral is an RDF notion, so it is only natural that the INFRA spec does not define it. But RDF literals go beyond \"string or number of boolean\" (they can have arbitrary datatypes).","issue_id":1667064560169,"origin_id":699872018,"user_origin_id":304612,"create_time":1601282955,"update_time":1601282955,"id":1668108139276,"updated_at":"2022-11-10T19:22:19.276000Z","created_at":"2022-11-10T19:22:19.276000Z"},{"_id":"636d4f6b1e434437e73dd02f","body":"Replying to @pchampin , 2 things\r\n### Round-tripping not in requirements\r\nThe point is, there is no official requirements for JSON-LD. Using a search engine with `json-ld requirements site:w3.org` , I found this \"Unofficial Draft 30 July 2014\" :\r\nhttps:\/\/dvcs.w3.org\/hg\/json-ld\/raw-file\/default\/requirements\/latest\/index.html\r\nwhich is not referenced in [json-ld11 normative-references](https:\/\/www.w3.org\/TR\/json-ld11\/#normative-references)\r\nWhile strict round-tripping is desirable, especially for testing purposes, I feel that it is in this case not possible given the gap too large between data models, namely the absence of global URL \/ URI \/ IRI identifiers in JSON specification.\r\n\r\n### Un-strict round-tripping already admitted in the API Recommendation\r\nSee [paragraph 8.6 Data Round Tripping](https:\/\/www.w3.org\/TR\/json-ld11-api\/#data-round-tripping)\r\nWhen the default `useNativeTypes = false` is applied, floating point rounding errors may occur.\r\nThis is another example where strict round-tripping does not occur.","issue_id":1667064560169,"origin_id":701237562,"user_origin_id":896281,"create_time":1601453701,"update_time":1601454441,"id":1668108139279,"updated_at":"2022-11-10T19:22:19.278000Z","created_at":"2022-11-10T19:22:19.278000Z"},{"_id":"636d4f6b1e434437e73dd030","body":"Round-tripping through RDF does impose some restrictions, but the general intent is to allow round-tripping between Expanded and Compacted modes. I think there is another case where we were not able to do this, and we have to way the desirability of a feature against the inability to round-trip. That certainly could be the case here, if there's sufficient support for this change.","issue_id":1667064560169,"origin_id":701564579,"user_origin_id":46296,"create_time":1601490433,"update_time":1601490433,"id":1668108139281,"updated_at":"2022-11-10T19:22:19.281000Z","created_at":"2022-11-10T19:22:19.281000Z"},{"_id":"636d4f6b1e434437e73dd031","body":"Looking at this again, i think it's inappropriate to consider this an Erratum, as it is not an error in the spec, rather an enhancement request to be considered in a future update. It is certainly in the class of \"minor\", but substantive, updates that might go in to an updated spec. Consequently, I'm changing the labeling (subject, of course, to further WG review).","issue_id":1667064560169,"origin_id":1280061132,"user_origin_id":46296,"create_time":1665955673,"update_time":1665955673,"id":1668108139284,"updated_at":"2022-11-10T19:22:19.284000Z","created_at":"2022-11-10T19:22:19.284000Z"}]

Point 8 in IRI Expansion https://www.w3.org/TR/json-ld11-api/#iri-expansion says nothing about an integer JSON value that is expanded to an IRI in presence of a base IRI . So this should be...

jmvanel

Default value of produceGeneralizedRdf should be false

[{"_id":"636d4f9ab928086c816f47e2","body":"Yes, the default should be `false`, which is consistent with the warning that it may go away in the future.","issue_id":1667064560172,"origin_id":653945821,"user_origin_id":46296,"create_time":1593987422,"update_time":1593987422,"id":1668108186977,"updated_at":"2022-11-10T19:23:06.976000Z","created_at":"2022-11-10T19:23:06.976000Z"},{"_id":"636d4f9ab928086c816f47e3","body":"Summary:\r\n\r\nThe default value of the [produceGeneralizedRdf](https:\/\/www.w3.org\/TR\/json-ld11-api\/#dom-jsonldoptions-producegeneralizedrdf) option should be `false`, not `true`.","issue_id":1667064560172,"origin_id":1280060309,"user_origin_id":46296,"create_time":1665955359,"update_time":1665955359,"id":1668108186979,"updated_at":"2022-11-10T19:23:06.979000Z","created_at":"2022-11-10T19:23:06.979000Z"}]

The definition of the [JsonLdOptions Type](https://www.w3.org/TR/json-ld11-api/#the-jsonldoptions-type) specifies that the default value for produceGeneralizedRdf is `true`. However, there are tests that fail if this is the case (e.g. the toRdf test...

kal

Which context should be used to get the term definition in compaction algorithm step 6?

[{"_id":"636d499fb928086c816f3f3c","body":"It seems that step 5 should look up the property-scoped context using _type-scoped context_ and not _active context_, although it does update the _active context_.\r\n\r\nPerhaps other implementors can comment, as I recall addressing this specifically, but don't see anything in the commit history.","issue_id":1667064560176,"origin_id":652621981,"user_origin_id":46296,"create_time":1593634139,"update_time":1593634139,"id":1668106655394,"updated_at":"2022-11-10T18:57:35.393000Z","created_at":"2022-11-10T18:57:35.393000Z"},{"_id":"636d499fb928086c816f3f3d","body":"My implementation is also failing on compact#c013, I believe for the same reason. Using `type-scoped context` allows me to pass this test without breaking previous passing tests.","issue_id":1667064560176,"origin_id":723316567,"user_origin_id":14182174,"create_time":1604699577,"update_time":1604699577,"id":1668106655396,"updated_at":"2022-11-10T18:57:35.396000Z","created_at":"2022-11-10T18:57:35.396000Z"},{"_id":"636d499fb928086c816f3f3e","body":"We have a backlog of updates to do to the spec, but the WG hasn't been active. It's captured as a raised erratum, which will eventually allow us to go fix the spec, and the WG has the ability to re-issue a REC, with the appropriate procedures.\r\n\r\nIn the meantime, please continue to reach out with issues we encounter.","issue_id":1667064560176,"origin_id":723352495,"user_origin_id":46296,"create_time":1604707237,"update_time":1604707237,"id":1668106655399,"updated_at":"2022-11-10T18:57:35.399000Z","created_at":"2022-11-10T18:57:35.399000Z"},{"_id":"636d499fb928086c816f3f3f","body":"Summary:\r\n\r\nUpdate step 6 of the [Compaction Algorithm](https:\/\/www.w3.org\/TR\/json-ld11-api\/#algorithm-6) to check the _type-scoped context_ instead of the _active context_.\r\n\r\n> 6) If the [term definition](https:\/\/www.w3.org\/TR\/json-ld11\/#dfn-term-definition) for _active property_ in _type-scoped context_ has a [local context](https:\/\/www.w3.org\/TR\/json-ld11\/#dfn-local-context):","issue_id":1667064560176,"origin_id":1280058534,"user_origin_id":46296,"create_time":1665954705,"update_time":1665954705,"id":1668106655402,"updated_at":"2022-11-10T18:57:35.401000Z","created_at":"2022-11-10T18:57:35.401000Z"}]

I was trying to get my implementation of the compaction algorithm to pass test c013 and I think that the spec may be misleading. Step 5 reverts `active context` if...

kal

Blank node as predicate tests

[{"_id":"636d4f6ab928086c816f479d","body":"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](https:\/\/www.w3.org\/TR\/json-ld11\/#dfn-property)).","issue_id":1667064560179,"origin_id":1275320367,"user_origin_id":46296,"create_time":1665525365,"update_time":1665525365,"id":1668108138781,"updated_at":"2022-11-10T19:22:18.780000Z","created_at":"2022-11-10T19:22:18.780000Z"},{"_id":"636d4f6ab928086c816f479e","body":"Actually, [expand test 0038](https:\/\/w3c.github.io\/json-ld-api\/tests\/expand-manifest.html#t0038) does test this (this is how I ran into this problem, actually), and it is marked with specVersion 1.0.\r\nNote 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.","issue_id":1667064560179,"origin_id":1275896908,"user_origin_id":304612,"create_time":1665568280,"update_time":1665568280,"id":1668108138785,"updated_at":"2022-11-10T19:22:18.784000Z","created_at":"2022-11-10T19:22:18.784000Z"},{"_id":"636d4f6ab928086c816f479f","body":"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.","issue_id":1667064560179,"origin_id":1276692295,"user_origin_id":109587,"create_time":1665606107,"update_time":1665606107,"id":1668108138790,"updated_at":"2022-11-10T19:22:18.790000Z","created_at":"2022-11-10T19:22:18.790000Z"},{"_id":"636d4f6ab928086c816f47a0","body":"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.","issue_id":1667064560179,"origin_id":1276782614,"user_origin_id":46296,"create_time":1665612364,"update_time":1665612364,"id":1668108138793,"updated_at":"2022-11-10T19:22:18.793000Z","created_at":"2022-11-10T19:22:18.793000Z"}]

From https://github.com/digitalbazaar/jsonld.js/issues/498. cc/ @pchampin @davidlehn (the same issue is present in PyLD: https://github.com/digitalbazaar/pyld/issues/167) Consider the following: ``` { "@context": { "t": "_:b" }, "@type": "t:x" } ``` It expands to...

gkellogg

missing instructions in Node Map generation

[{"_id":"636d4b3eb4ee765e3b0e63e1","body":"Sorry, a bit confused. Step 6.10 is the following:\r\n\r\n> 6.10) If _element+ has an `@graph` [entry](https:\/\/infra.spec.whatwg.org\/#map-entry), recursively invoke this algorithm passing the value of the `@graph` [entry](https:\/\/infra.spec.whatwg.org\/#map-entry) for _element_, _node map_, and _id_ for _active graph_ before removing the `@graph` [entry](https:\/\/infra.spec.whatwg.org\/#map-entry) from _element_.\r\n\r\nIn fact, when searching the document (both TR and ED), I can't find a sentence \"if node map does not contain an id entry, create one and initialize its value to an empty map\".\r\n\r\nThe algorithm takes _node map_ as an input argument, so it definitely must already exist. The places which recursively invoke the algorithm pass the existing _node map_, so I don't see the specific issue.","issue_id":1667064560184,"origin_id":1272402183,"user_origin_id":46296,"create_time":1665265498,"update_time":1665265498,"id":1668107070161,"updated_at":"2022-11-10T19:04:30.161000Z","created_at":"2022-11-10T19:04:30.161000Z"},{"_id":"636d4b3eb4ee765e3b0e63e2","body":"The sentence I wrote (\"if node map does not contain an id entry...\") is what I suggest to add to step 6.10 . So indeed, it is currently not in the spec :-)\r\n\r\nOf course <var>node map<\/var> always exists. What does not always exist, when entering 6.10, is an entry in <var>node map<\/var> whose key is <var>id<\/var>. When the algorithm is recursively invoked, passing <var>node map<\/var> and passing <var>id<\/var> for <var>active graph<\/var>, this entry is assumed to exist at step 2.\r\n\r\nBy adding the suggested sentence in 6.10 before the recursive invocation, we ensure that this assumption in the invoked step 2 is satisfied.","issue_id":1667064560184,"origin_id":1276085833,"user_origin_id":304612,"create_time":1665577865,"update_time":1665577865,"id":1668107070166,"updated_at":"2022-11-10T19:04:30.166000Z","created_at":"2022-11-10T19:04:30.166000Z"}]

I believe that an instruction is missing from step 6.10 of [Node Map Generation](https://www.w3.org/TR/json-ld11-api/#node-map-generation), namely: - if node map does not contain an id entry, create one and initialize its...

pchampin