solid
Create serialization format goals and strategy
Document our goals/intentions: explicitly write down what we want (and do not want) to achieve with serialization.
- For dereferenceable resources (distinct from ephemeral messages that are being passed), one should be able to publish them from a Solid Storage in a reliable way. (Including any storage backed by quad store / SPARQL endpoint)
- Clients should be able to work with just one parser, especially PWA/SPA which needs to keep their bundles low
- Turtle/Trig parser can be very efficient
- JSON-LD parser might be easier when the client is also compacting and/or framing internally
@elf-pavlik Thanks! Could you detail/specify "reliable" in your comment above?
For dereferenceable resources (distinct from ephemeral messages that are being passed), one should be able to publish them from a Solid Storage in a reliable way. (Including any storage backed by quad store / SPARQL endpoint)
To my understanding, Solid Storage does NOT guarantee preserving any formatting specific to the serialization used to set the full state of the RDF Source. This includes Turtle comments and prefixes, as well as JSON-LD @context and framing.
While some implementations may choose to preserve those details, or it can happen as a simple consequence of using a specific configuration (e.g. filesystem-based persistence). As long as requirements in the spec do not guarantee that, I think we should consider it unreliable.
NOTE: I don't think spec should guarantee storage to preserve format details for specific RDF serialization, if this needs to be discussed there are separate issues already open
For the record, I do not have any preferences, not do I propose that this issue becomes a discussion of such preferences. Rather, this is a work item that needs to be carried out, and specific discussion probably need specific issues.
I've created #465 as a place to discuss these preferences.
