Re: JSON-LD: Please keep @base

Thanks for your helpful response.

On Wed, May 1, 2013 at 2:44 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> 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



> 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).


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 :)


>>   "bundle": "../",
> If you look at the JSON-LD grammar, specifically the section Context Definitions:
>
> http://www.w3.org/TR/json-ld/#context-definitions
>
> You'll see that such a definition is illegal. It has to be an absolute IRI. The playground on json-ld.org seems to accept it nevertheless and the algorithms actually don't verify it. I've CC'ed Dave Longley who implemented the JSON-LD processor used for the playground.

>> 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 :)

> 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.


> Yeah, it looks quite simple but I find it highly confusing and also inconsistent to what other technologies do. Think of an external CSS file for example. All relative URLs there are also resolved against the CSS file and not the HTML file that includes it. How should the following context be resolved according to you

Yes, I mean the regular way of resolving the relative URIs would be
what I expected, but after reading the specification drafts and
discussing with Manu I understood that they are just treated
literally.


>     "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.


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

I'm OK if @base is not supported from an external @context and agree
that would be confusing (and if it was to remain, one would have
explain such edge cases).


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.


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Wednesday, 1 May 2013 14:25:13 UTC