- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 1 May 2013 14:04:08 +0100
- To: public-linked-json@w3.org
I also sent this to public-rdf-comments@w3.org ---------- Forwarded message ---------- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> Date: Wed, May 1, 2013 at 1:52 PM Subject: JSON-LD: Please keep @base To: public-rdf-comments@w3.org 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 -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Wednesday, 1 May 2013 13:04:56 UTC