Re: A use case for @vocab?

Hi François,

On May 24, 2012, at 6:52 AM, "François Daoust" <francois@joshfire.com> wrote:

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

As I recall, it was more a matter of not confusing things at that point. If the community found value in something like @vocab, we could re-visit. As I recall, both Niklas and I supported this use, but agreed to defer the issue.

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

FYI, check out http://niklasl.github.com/rdfa-lab/. Niklasl is way ahead, although it still needs some work.

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

Or framing.

Given the incomplete state of the RDF API, there has been some interest in considering if a JSON-LD transformation might be more useful, and allow the whole JSON-LD API to work with it.

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

Compact is pretty, but framed probably works best to actually work with the data.

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

Transforming RDFa that uses @vocab to JSON-LD that uses @vocab has a nice symmetry.

> 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 14:47:16 UTC