Make `rdfstar` an multiple-choice option rather than a flag about json-ld-star HOT 7 CLOSED

I agree that there is no trivial way to convert back from "unstared" RDF to RDF-star, regardless of the method. I was not even suggesting we try to support it. All this, I guess, makes it a rather ad-hoc feature, that probably does not deserve to be integrated in the spec, after all... WDYT?

from json-ld-star.

I think better is a more generic specification for "reifying" RDF-star into normal RDF and back again; either/both using the reification vocabulary or named graphs. No need to make it a JSON-LD-specific thing.

from json-ld-star.

Interesting idea. It might be a bit confusing to use “graph”, as they could easily be confused with names graphs. An interesting merger could consider unnamed names graphs as N3- like graphs /: a more general case than an embedded triple. Many uses of unnamed names graphs (where the property value is a graph, and there is no explicit graph name) come fro Verifiable Claims.

from json-ld-star.

It might be a bit confusing to use “graph”, as they could easily be confused with names graphs.

Sorry but I don't quite understand this remark.

I realize that my proposal above is ambiguous about when this option is applied, maybe that's where the confusion comes from. My idea was to alter the way toRdf works, not other algorithms (very similarly to the way we handle direction in literals).

Alternatively, we could imagine that the conversion (from RDF-star to reification or named graph) happens earlier, e.g. during the expansion... but that's not what I had in mind, and I am not sure I like that idea.

Thinking a little more about it, maybe it should not be the job of the JSON-LD processor to do this kind of "post-processing". After all, nothing in it is JSON-LD specific...

from json-ld-star.

I'm definitely conflating issues; I think that your proposal would be specifically for embedded nodes and annotation objects, that rather than creating an embedded triple, it would create an N3-style graph containing that triple (although, this gets to the re-use issue). For example Example 3 might be rendered in N3 as follows:

@prefix : <http://example.org/> .
{:bob :age 42} :certainty 0.8e0 .

But, in light of your statement above, maybe it would be closer to using named graphs (expressed in TriG), setting aside that lack of named-graph semantics for now:

@prefix : <http://example.org/> .
GRAPH _:g  {:bob :age 42} .
_:g :certainty 0.8e0 .

My comment was about a larger change to interpreting graph-container values in JSON-LD, which is in line with my ideas about how JSON-LD could be considered an alternative syntax for N3 reasoning, but it may, as you suggest, be better to leave this as a mapping from RDF Named Graphs to N3 quoted graphs.

from json-ld-star.

My comment was about a larger change to interpreting graph-container values in JSON-LD, which is in line with my ideas about how JSON-LD could be considered an alternative syntax for N3 reasoning,

I was definitely not going that far 😅 (interesting as this idea is!)

from json-ld-star.

A problem with the named-graph approach is when converting from RDF, how do you distinguish a triple in a named graph which should become an embedded triple from a named graph which would be serialized using @id and @graph? Also, are triples in named graphs not asserted?

Its easier to see for the Reification case, although arguably, the reification triples are contained in some graph, unlike embedded triples that are not annotated.

from json-ld-star.