- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 10 Mar 2014 18:13:59 +0100
- To: "'Linked JSON'" <public-linked-json@w3.org>
On Monday, March 10, 2014 5:27 PM, Sandro Hawke wrote: > On 03/10/2014 12:18 PM, Markus Lanthaler wrote: > > On Monday, March 10, 2014 3:13 PM, Sandro Hawke > >> On 03/10/2014 09:58 AM, Markus Lanthaler wrote: > >>> On Saturday, March 08, 2014 8:13 PM, David Janes wrote: > > [...] > >>>> (2) "/" routed IRIs > >>>> > >>>> Instead of returning various @base relative IRIs as > >>>> "../../../x/y/z", > >>>> it would be nice if there was an option for just getting "/x/y/z". > >>> Can't you achieve that by simply setting the base to the domain > >>> instead of some directory? So, http://example.com/ instead of > >>> http://example.com/a/directory/ > >> I'm not sure what you mean by "setting the base", > > Expansion transforms everything to absolute IRIs. Compaction > transforms > > absolute IRIs to IRIs relative to the specified base. Thus, if you > set the > > base to the domain and not a subdirectory you'd get almost the same > result. > > > > > >> but whatever the base > >> is, a relative URI of "/x/y/z" should have exactly the behavior I > think > >> David is asking for, just by the rules of Relative URI resolution. > > Yeah, it's an absolute path instead of a relative one. If you have > two > > JSON-LD files in a directory that reference each other and move both > of them > > to a new directory, absolute-path IRIs break, relative paths don't. > That's > > why we preferred relative paths. That being said, implementations > could > > easily add a flag to produce absolute-paths instead of relative ones. > > Makes sense. > > Getting back to what David said... He said he wanted to be able to do > say "/x/y/z" not just "../../../x/y/z". He said: Instead of returning various @base relative IRIs as "../../../x/y/z", it would be nice if there was an option for just getting "/x/y/z". ... which I interpreted as the result of an API call. > So my point is that anywhere > "../../../x/y/z" works, "/x/y/z" must as well, according to the URI > spec. In other words, he already has what he wants. If the Yep. It's of course legal JSON-LD > software isn't giving him that, the software is broken. Or does JSON-LD > somehow overriding the URI spec on this? Nope. But the test suite expects relative path IRIs as result not path-absolute ones. So all implementations do that and AFAIK none of them offer a flag return path-absolute IRIs instead at the moment. -- Markus Lanthaler @markuslanthaler
Received on Monday, 10 March 2014 17:14:37 UTC