A use case for @vocab?

Hi,

A few months ago, the group decided to drop @vocab (and @base) from
the JSON-LD documentation. I wonder whether that decision could be
revisited.

Looking at minutes and issues [1], I'd say the rationale to drop
@vocab was roughly:
- to keep things simple, trying not to introduce new keywords when not
necessary.
- because @vocab does not add much to the syntax since you may simply
list the vocabulary in @context and you'd end up with the same thing
as @vocab, only more explicit
- because there are no clear use cases to keep it around
I probably missed or misunderstood a few arguments. Again, feel free
to complete or correct me!

I propose another angle below. Well, I think. I apologize if you've
already discussed that over and over. I may also be entirely wrong on
my assumptions about the spec ;)


Context
=====
A Web application runs client-side on a mobile device. It takes the
URI of a Web page that embeds linked data somehow, e.g. using RDFa, as
parameter and does something with that data. Typically it renders the
data in tabs, grids, whatever.

The Web application runs in two steps:
 1. it fetches the Web page (ignoring same origin policy concerns for
a minute) and converts the linked data to a JSON-LD structure
 2. it renders the resulting JSON-LD structure.
Splitting the processing in two steps is not just for fun, it helps a
lot to keep things modular, switch to other types of structured data,
and reuse existing code.

To restrict the size of the resulting Web application (rendering
arbitrary items in a meaningful way is next to impossible), there are
a few additional constraints on the data:
- it uses a core vocabulary as much as possible, typically schema.org,
although the Web application certainly does not support the full type
hierarchy and properties of that core vocabulary.
- it may contain a few useful properties from other common
vocabularies: foaf, ical, good relations, etc.


Problem
=====
To generate the JSON-LD structure at step 1, the Web application needs to:
1. include an RDFa processor (e.g. green-turtle [2])
2. convert the triples into a JSON-LD structure, typically using the
"fromRDF" algorithm defined in the JSON-LD API (using a library such
as jsonld.js [3])
3. run the compaction algorithm defined in the JSON-LD API (jsonld.js
does that as well)

Third step is needed because the compact form is the easiest one to
process in an application. However, this step obviously requires to
pass the @context to use for compaction. This is where the problem
occurs.

As things stand (and provided I got thing correctly), the Web
application needs to pass the full list of individual properties it
knows of in the core vocabulary to end up with a "flat" structure. The
only way not to end up with a full list is to define a prefix, e.g.
"core", but that prefix would then appear in the resulting structure
as in:
 {
  "@context": { "core": "http://example.org/corevocab#" },
  "core:name": "Foo",
  "core:description": "Blah"
 }

... whereas I'd really want to end up with a structure that is
slightly easier to process in code:
 {
  "@context": { [[some magic to set core vocab as default vocab]] },
  "name": "Foo",
  "description": "Blah"
 }

Having to specify the full list of properties would require shipping a
large structure to the thin client for basically nothing. If the app
restricts itself to listing known properties, the list becomes hard to
maintain as the app evolves.


Proposed solution
=====
The solution would be to re-introduce "@vocab" to end up with:
 {
  "@context": { "@vocab": "http://example.org/corevocab#" },
  "name": "Foo",
  "description": "Blah"
 }
... and more importantly to be able to pass that kind of context to
the compaction algorithm.

Did I miss something?
Are unknown properties associated with an hypothetical base URI of the
JSON-LD document?

(Obviously, another possible solution would be to implement a
dedicated compaction algorithm for the use case mentioned but that
would kind of defeat the ability to reuse existing "standard-to-be"
libraries to perform the conversion)

Thanks,
Francois.

[1] https://github.com/json-ld/json-ld.org/issues/26
[2] http://code.google.com/p/green-turtle/
[3] https://github.com/digitalbazaar/jsonld.js

Received on Thursday, 24 May 2012 13:50:14 UTC