- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 14 Jan 2013 19:05:49 +0100
- To: "'Manu Sporny'" <msporny@digitalbazaar.com>
- Cc: <public-linked-json@w3.org>, "'RDF WG'" <public-rdf-wg@w3.org>
On Monday, January 14, 2013 6:40 PM, Manu Sporny wrote > The problem in a nutshell is that we store JSON-LD data in compact form > (to save space in the database). Thus, if the library was used in its > default configuration, and a base URL was passed to the library, then > all @id paths would become relative before storing the document. > > If a developer fails to store the base URL, or set the base URL to > null, > then they lose the URL forever. My concern is that others may start > doing this as well and not know about the nuance. I'm concerned about > this being the default behavior. How is that different from storing the retrieved document directly (without re-compacting it)? > There is an argument that surely people will catch this before a system > goes into production, but I think it's the aggressive optimization that > I find concerning. I'd rather there is a flag that says "optimize @id > URLs", than just do it by default... because when you do it, you lose > information and the only way to get that information back is to make > sure your application remembers the lost information. I understand your concerns but I don't think it will be a problem in practice. Actually I think it will be the other way round.. developers usually prefer relative URLs and want to keep them relative when re-compacting so we shouldn't hide this behavior in a flag. Lets discuss it in tomorrow's telecon. Cheers, Markus -- Markus Lanthaler @markuslanthaler
Received on Monday, 14 January 2013 18:06:21 UTC