RE: JSON-LD: Please keep @base

On Wednesday, May 01, 2013 4:24 PM, Stian Soiland-Reyes wrote:
> On Wed, May 1, 2013 at 2:44 PM, Markus Lanthaler wrote:
> 
> > Doesn't really matter but you might wanna change the file extension
> to .jsonld (that's the recommended extension).
> 
> I went for .json as it works out of the box many places (for instance
> at the github site where I host the context), and because I intend for
> users to not have to know it's JSON-LD. However I've declared the
> media-type internally to be application/ld+json - see Example 2 at
> http://wf4ever.github.io/ro/bundle/#ucf

Fair enough


> > Interesting approach. Although I don't really understand your usage
> of relative URLs. Let's assume the ZIP file is located at
> http://example.com/wf4ever-sample.zip You seem to use URLs in a way
> which would imply that there, e.g., exists a resource at
> http://example.com/file.txt - which doesn't in most cases, right? What
> if there indeed exists such a file but it is a completely unrelated
> file?
> 
> No, that would only work if you assume the resources come from a
> 'virtual' root directory at
> 
>   http://example.com/wf4ever-sample.zip/
> e.g.
>   http://example.com/wf4ever-sample.zip/file.txt
> 
> I've proposed some options at
> http://wf4ever.github.io/ro/bundle/#absolute-uris but not really
> decided on any of them yet - the above is option #1 which gives
> easiest solution for relative references, but HTTP-wise would give a
> misleading 404s (without additional configuration).

Right, that's what I meant. It would result in a 404.


> Other options:
>   http://example.com/example1.robundle#folder/helloworld.txt
>   jar:http://example.com/example1.robundle!/folder/helloworld.txt
>   widget://8191dee8-0b8e-452d-8d64-7706a140185e/folder/helloworld.txt
> 
> Any advice from the experts welcome :)

I wouldn't call myself an expert but I find the fragment identifier or widget URI scheme options to be the most compelling. The widget URI scheme would work without problems with JSON-LD. The fragment identifier solution is still a bit problematic unless you change your JSON to something like

  "aggregates": [
     "#folder/soup.jpeg",
     "#hello.txt" ]

or

  "aggregates": [
     "#/folder/soup.jpeg",
     "#/hello.txt" ]

Using the bundle prefix would require you to define its full URL according the current spec.

 
> >> The value of keys that are not keywords must be either an absolute
> IRI, a compact IRI, a term, a blank node identifier, a keyword, null,
> or an expanded term definition.
> 
> Argh.. You are right.  I will have to rethink this then.
> 
> Actually it was in discussions with Manu Sporny who suggested this
> approach on IRC (2013-02-28) as we discussed @base.
> 
> 18:30 < manu-db> re: 'root' as a prefix... you could also use
> something like: "package": "../" - and then your IDs could be:
> 'annotates': 'package:soup.jpeg' ?
> 18:30 < manu-db> that way, it looks like a special new IRI scheme (but
> it isn't, just a regular 'ol IRI)
> 18:47 < stain> that's quite clever :)

Yeah, we still haven't resolved that issue yet but at least in all recent discussion we agreed that we don't want to support relative base URLs.

Here's the issue tracking (most) discussions

  https://github.com/json-ld/json-ld.org/issues/223

The rest has been discussed in telecons and is documented here:

  http://json-ld.org/minutes


> > That wasn't intended and we probably should throw an error instead as
> it is ambiguous relative to which base URL such a definition is
> resolved.
> 
> Yes, the spec would otherwise have to make this very obvious.

Right. I do that already in my implementation. You can use my playground to cross-check things like these:

  http://www.markus-lanthaler.com/jsonld/playground/


> >     "aggregates": [
> >        "../folder/soup.jpeg",
> >        "../hello.txt" ]
> 
> Yes, this would of course work, but anyone dealing with this as JSON,
> and not JSON-LD, would find it unnatural to list of files (which is at
> the core of my concept of RO bundle) as "../something" rather than
> "something" - most likely they would get this wrong somewhere.

Why do you think it is annoying? Actually I think it the processing a lot simpler for people using it as JSON. When they process the manifest, they are in that working directory. Every programming language I know of allows relative paths to be resolved against the current working directory. So you would get that for free. On the other hand, if you use something like bundle:xxx you have to pre-process that value somehow to get to an absolute path that you can use to access the file. The same is true if you are talking about URLs. I'm also convinced that developers will understand that intuitively as that's what they do all the time.


> So given your clarification, then I would then strongly request @base
> to remain supported - ALLOWING a relative URI reference.

I'm still not convinced about that. Just the discussion we are having shows how confusing it is -- and you clearly spend quite some time thinking about these things.


> My last workaround would of course be to simply move my manifest to
> the root folder, say as ".ro_manifest.json". I did not like this
> option as I need the ".ro/" folder anyway for annotations and other
> meta-resources (such as provenance) and would try to avoid cluttering
> the bundle when viewed as a regular ZIP.

That would indeed be the simplest solution :-)


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 3 May 2013 09:02:54 UTC