RE: JSON-LD: Please keep @base

On Wednesday, May 01, 2013 2:53 PM, Stian Soiland-Reyes wrote:

> First of all, congratulations on the great work on the JSON-LD
> specification (http://www.w3.org/TR/2013/WD-json-ld-20130411/)

Thanks :-)


> I am developing a specification for a Research Object Data Bundle [1]
> - note that this is work in progress, although comments are of course
> welcome.

Very interesting.. thanks for letting us know.


> Research Objects are BTW the topic of the newly formed W3C Community
> Group ROSC [2]).
> 
> A short summary of my application:
> * A UCF/OCF-compliant ZIP-file with aggregated resources. Folder .ro/
> is reserved
> * Manifest in .ro/manifest.json  (JSON-LD) - listing files and their
> metadata; also allows external resources (URIs) to be aggregated -
> based on ORE and RO models

Doesn't really matter but you might wanna change the file extension to .jsonld (that's the recommended extension).


> I notice that in http://www.w3.org/TR/json-ld/#base-iri it says @base
> is a feature "AT RISK", and I would here ask for this feature to be
> INCLUDED in the JSON-LD specificaiton.

OK


> >From my manifest.json I have a need to "climb up" of the .ro/ folder,
> to avoid referring to all files as say "../file.txt".  The RO Bundle
> is a ZIP file, and so may be located anywhere on the web (or perhaps
> just on the local file system), and so it's not possible to refer to
> the bundled files by anything other than relative URI references.

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?


> The @base directive would have made this much easier for me, but due
> to it being "at risk", I have for the moment not included it, and
> instead applied a @context prefix:
> 
> 
>   "bundle": "../",
> 
> and use it like this:
> 
>   "aggregates": [
>      "bundle:folder/soup.jpeg",
>      "bundle:hello.txt" ]

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.

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.


> I see you have concerns about relative paths, and what is the meaning
> of @base when it appears in an included @context - and I can fully
> understand this. However, I think given the current mechanism of
> prefixes being resolved "in place" rather than from where they are
> located, then @base should be treated the same way, meaning that my
> use-case would work as:

As said above, that's probably a "bug".


> Assume <http://purl.org/wf4ever/ro-bundle/context.json> contains:
> 
> {
>   "@context": {
>     "@base": "../"
>     "ore": "http://www.openarchives.org/ore/terms/"
>     "aggregates": "ore:aggregates"
>   }
> }
> 
> 
> 
> and a given .ro/manifest.json (say inside
> http://example.com/robundle2.zip) has:
> 
> {
>   "@context":  "http://purl.org/wf4ever/ro-bundle/context.json",
>   "aggregates": [
>      "folder/soup.jpeg",
>      "hello.txt" ]
> }
> 
> 
> This means I can just unzip my RO bundle on a web server, and it is
> perfectly valid linked data out of the box.

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

{
  "@context": {
    "@base": "../"
    "term": "/vocab#aggregates"
  }
}

Why don't you wanna use relative URLs directly. Instead of

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

you could just write 

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

Wouldn't that also be much easier for developers to understand? Also for developers which use the JSON-LD as JSON?


Cheers,
Markus



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 1 May 2013 13:44:53 UTC