W3C home > Mailing lists > Public > public-rdf-wg@w3.org > January 2013

RE: Intent to close ISSUE-204

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>
Message-ID: <025001cdf281$cb761970$62624c50$@lanthaler@gmx.net>
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.


Markus Lanthaler
Received on Monday, 14 January 2013 18:06:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:24 UTC