JSON-LD: Please keep @base

Hi!

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

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.

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
* Annotations about these resources, using the Open Annotation Core Model.


I have found JSON-LD to be a very good alternative to lower the entry
barrier for developers to (possibly unknowingly) be creating Linked
Data - JSON is widely known and supported in a myriad of platform; and
in my specification I have specified a "restricted" JSON-LD profile
meaning that clients can read and write my manifest as if it is just
JSON.


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.


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


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

This works even when the @context is loaded from remotely, because
unlike other prefixes in other RDF syntaxes, JSON-LD prefixes has the
(here) nice feature that they are resolved as if the whole @context
was literally there in the document.


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:


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.


[1] http://purl.org/wf4ever/ro-bundle
[2] http://www.w3.org/community/rosc/


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

Received on Wednesday, 1 May 2013 12:53:21 UTC