@helge @julian i don't think the bugs would go down.
-
-
-
@julian it literally would be! instead of 100 different attempts at producing almost any json, you would have everything coerced into a data model with a single canonical output that can be serialized deterministically
-
Serious answer: If a "proper json-ld processor" existed, we could have this talk.
Current state: json-ld is immature, and such a thing is fiction.
-
Serious answer: If a "proper json-ld processor" existed, we could have this talk.
Current state: json-ld is immature, and such a thing is fiction.
@helge @julian several do, but not in all languages. here are the ones that conform to the test suite https://json-ld.org > "developers"
without a json-ld processor, you will end up reimplementing parts of json-ld anyway, and you have to be consistent with something whose definition you are unaware of. is your Public my Public? which natural language is that string? is that even a string, or is it actually a reference? json-ld is one answer. the other answer would be a central registry.
-
@helge @julian several do, but not in all languages. here are the ones that conform to the test suite https://json-ld.org > "developers"
without a json-ld processor, you will end up reimplementing parts of json-ld anyway, and you have to be consistent with something whose definition you are unaware of. is your Public my Public? which natural language is that string? is that even a string, or is it actually a reference? json-ld is one answer. the other answer would be a central registry.
@helge @julian of course, if you had a central registry of allowed symbols and their definitions, then that means you can't just add whatever you want to extend the data. we've seen this in atproto where the end result of their lexicons is that you have to create sidecar records and have prior out-of-band knowledge on which lexicons you need to check.
-
@helge @julian of course, if you had a central registry of allowed symbols and their definitions, then that means you can't just add whatever you want to extend the data. we've seen this in atproto where the end result of their lexicons is that you have to create sidecar records and have prior out-of-band knowledge on which lexicons you need to check.
@helge @julian with that said: we'd have less complexity if everyone used fully expanded jsonld without any context, because that would make it so that there's exactly one correct canonical way to express anything
...at the cost of readability. which is really why context exists: to allow for using more readable shorthand, without losing the mapping to the unambiguous form. with enough context you should be able to map any arbitrary json to an unambiguous generic entity-attribute-value graph.
