woke up randomly thinking about how maybe the existence of “typed values” in jsonld might encourage people to treat context as a schema when it is not that at all; at most, context is a coercion mechanism or reshaper.
-
woke up randomly thinking about how maybe the existence of “typed values” in jsonld might encourage people to treat context as a schema when it is not that at all; at most, context is a coercion mechanism or reshaper. it’s all strings or things
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
i mean stuff like
{
“@.value”: “42”
“@.type”: “xsd:integer”
}this is in some roundabout way *useful*, sure — 42 is an integer! — but it’s missing the point. you could just directly do
{
“@.value”: 42
}because jsonld is also json. and on an RDF level it gets converted to the former, ie in turtle or n-triples
“42”^^xsd:integer
which is equivalent to the following in turtle
42
basically if your serialization format has support for data types like integers and booleans, just use those!
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
consequently i have seen some context authors try to add @.type to their term definitions as a form of schematic precision when they really shouldn’t be doing that. the language processor will do that for you if need be. the jsonld-to-rdf algorithm already handles the basic json data types. sure, there’s some precision loss if you cast to xsd:integer instead of xsd:nonNegativeInteger, but again i think this is mixing concerns. most languages or serializations don’t make the distinction of +/-int
