Thing Description Framing for RDF/JSON-LD round-tripping

[ethieblin]

Hello,
We are currently working on an application which aims at round-tripping TD descriptions while storing them in a SPARQL endpoint.
We started creating a JSON-LD frame to do so.
Even if it is very simple, we thought we could share it here if it helps others:

{"@context":["https://www.w3.org/2019/wot/td/v1"],
 "@type":"Thing"}

Why compaction with the context is not enough:

• Initial TD and output to NTriples
• Compaction of the triples transformed into JSON-LD by Fuseki
• Framing of the triples transformed into JSON-LD by Fuseki

[ethieblin]

@vcharpenay if you want to take a look :)

[mmccool]

Seems a reasonable place to add some comments:

1. Canonicalization adds some requirements, like preservation of array order, that need to be addressed. See also Array of Forms ordering #1188
2. We don't actually NEED to express output from SPARQL queries as TDs, i.e. framed docs. If we relax this to just return JSON-LD and not (necessarily) valid TDs we can avoid the issue of round-tripping here. It is still useful, since you can use SPAQRL to e.g. find TD ids and then look up the actual TDs with a followup JSONpath query.
3. We need to look again at canonicalization requirements in general on processors (including directories), e.g. for preserving names (this no longer needed for signing as currently proposed, since it uses expanded form).
4. LDS proposal uses RDF as canonical form. Should we be doing that? Arguments: RDF canonical form expensive; JSON processing only useful? What are the actual costs (memory, compute time) of RDF processing?

[mmccool]

Discussion:

• Canonicalization and framing are important for testing, at least.
• Array ordering is still a problem; context needs to use list, not set, for all arrays (preferred solution). Alt solution would be to sort array "sets" during canonicalization, but this is a nuisance. Final solution would just be to sort when testing.
• We have to decide if TDD round-tripping is necessary. McCool's opinion: not necessary for SPARQL, can use to e.g. extract ids, then use JSON Path to get TDs that-are-TDs. SPARQL can return non-TD JSON-LD. Andrea: implementation that uses an RDF database internally still needs framing to satisfy JSON Path queries (to convert the RDF representation back into a validatable TD). Christian: when and where do we need input and output TDs to be the same? McCool: mostly this came up in the context of signing but canonical form takes care of most of the issues there... but processors (including directories) need to still respect array ordering.

[mmccool]

• McCool: still need framing in order to implement JSON Path queries on top of an RDF database. Still, that means we need framing for the implementation, but not for the specification. To make it easier to build workarounds though, perhaps we don't NEED to require that SPARQL queries themselves return valid TDs.
• Andrea: This is really an issue of TDs (framing, order) not of discovery. These issues arise in any kind of RDF processing. The @Set->@list will solve most problems, though.

[mmccool]

Discussion (discovery 2022.9.5): is not for discovery per se, but useful for validation, etc. Will mark as convert to TD issue, take off resolve by CR.

[egekorkan]

Related to #1968