You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I get the result above in the [playground], and with all the implementations I have tested (Rust, Ruby, Jena, PyLD), so although I didn't check the algorithm yet, I assume this is a compliant behevior, but I find it both annoying and counter-intuitive. The reason I find it counter-intuitive is that "regular" properties (as opposed to an alias of @type) work as expected. For example, if you replace "@id": "@type" with "@id": "rdf:type" in line 6 of the example above, you get the expected result (again, in all tested implementations).
Should this be considered as a spec bug?
The text was updated successfully, but these errors were encountered:
Sometimes, it makes sense to have a JSON property be an alias of
@type
/rdf:type
, and interpret the value in a particular vocabulary. E.g.to generate the following triple
Unfortunately, it does not work, and generates instead (the object is different):
I get the result above in the [playground], and with all the implementations I have tested (Rust, Ruby, Jena, PyLD), so although I didn't check the algorithm yet, I assume this is a compliant behevior, but I find it both annoying and counter-intuitive. The reason I find it counter-intuitive is that "regular" properties (as opposed to an alias of
@type
) work as expected. For example, if you replace"@id": "@type"
with"@id": "rdf:type"
in line 6 of the example above, you get the expected result (again, in all tested implementations).Should this be considered as a spec bug?
The text was updated successfully, but these errors were encountered: