RE: Intent to close ISSUE-204

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