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

ne 12. 5. 2024 v 19:55 odesílatel Michael Thornburgh <zenomt@zenomt.com>
napsal:

>
> > 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"?
>

Excellent catches, thanks.

Definitely allow fragids and relative URIs consistent with JSON-LD
including "".

Bnodes, I've not really thought about. I'm hopeful that it might not be
needed, or could fall back to some standard techiques.

Definitely graphs and cycles as well as trees.


>
> > 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>",
>     ...
>

Yes, new syntax which would be transpiled

"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.
>

Totally agree.  Just wouldnt it be nice if JSON itself has this syntax.

Given your feedback, it's probably sensible not to tackle this part.

Was thinking more along the lines of a new shorthand that gets transpiled,
much how many javascript things such as JSX get transpiled.  But this is
likely going to be more effort than it's worth, and confuse the base use
case.

Thank you again for feedback, I will change the text to include relative
URIs and fragids.


>
> >
> > Best
> > Melvin
>
> -michael thornburgh
>
>