Re: Random JSON-LD requests for the future: @job & slash-rooted paths

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".   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 software 
isn't giving him that, the software is broken.    Or does JSON-LD 
somehow overriding the URI spec on this?

       -- Sandro


>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Monday, 10 March 2014 16:27:53 UTC