Re: a simplified Turtle-like profile for JSON-LD

> On May 12, 2024, at 9:42 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> ne 31. 3. 2024 v 12:19 odesílatel Michael C. Thornburgh <zenomt@zenomt.com> napsal:
> 
> i propose a simplified profile of JSON-LD, inspired by Turtle:
> 
> Hi Michael

hi Melvin.

> 
> This is great work.  You inspired me to create a minimal subset of JSON-LD, which focuses on the @id part:
> 
> https://linkedobjects.org/Linked-JSON
> 
> It's called Linked-JSON, and simply aims to make URIs in JSON first class.  Community feedback is welcome.  Slight interest so far, one researcher at a uni seems to like it.  If there's more I'll make some libraries.

interesting. in your micro-spec you say

> The @id key associates a URI with the enclosing JSON object. This URI serves as a hyperlink to an external resource that provides additional information about the object.

a few questions to be taken as prompts for discussion or further exploration: does such a link always need to be an "external resource"? that is, would you also use this mechanism to name a node/sub-resource (for example with a fragment identifier) so that you could refer to it elsewhere (in the same document or elsewhere)? would you want to be able to name a node/sub-resource with something like a blank node identifier, so that you could refer to it in the same document but not with an externally-meaningful URI? should you be able to use relative URI references, or only absolute URIs? JSON lets you represent trees; would you want to be able to have, or represent, cycles or other non-tree directed graph shapes (moot if you can't name and refer to sub-resources in the document), or just stick to "this is a convention for indicating a URI in JSON"?

> There is one more possible extension that could align with turtle, and that is to put <URIs> in angle brackets and then transpile them to JSON-LD.  Unsure whether or not that's a good idea, but it would make JSON(-LD) look a bit more like turtle.  That part is not yet in the spec, just playing around with the idea.

do you mean a new beyond-JSON serialization syntax with a new way of delimiting URIs, like

    ...
    "foo": <someUri>,
    ...

or do you mean indicating that a string value is a URI by having the first and last characters be '<' and '>' respectively, like

    ...
    "foo": "<someUri>",
    ...

in the first case, that has a huge activation energy and adds significant complexity since now you need a full-on text parser for "JSON plus this extension", which is a PITA. one of the best arguments for plain-old JSON as a general base serialization is that every useful language/environment either supports JSON out of the box or someone's already written a JSON serializer/deserializer for you. for the second case, you'd want to still be able to express strings that begin with '<' somehow i'd imagine, so you'd need some escape mechanism.

> 
> Best
> Melvin

-michael thornburgh

Received on Sunday, 12 May 2024 17:55:40 UTC