RE: A use case for @vocab?

Hi François,

good to hear that Joshfire is still interested in JSON-LD :-) Let's go straight to the

> 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 Gregg already said, you probably should consider framing as this allows you to "shape" your data in useful from to make the rendering as easy as possible. 


> 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

Sure.. how should the API otherwise know what you mean by, e.g., "name"?

 
> Having to specify the full list of properties would require shipping a
> large structure to the thin client for basically nothing.

Why for nothing? You are describing above a quite common use case..


> If the app
> restricts itself to listing known properties, the list becomes hard to
> maintain as the app evolves.

Not so sure if I buy this.. The list grows as the app supports more things, so why should it be a problem to "document" that? On the other hand you could of use prefixes as you stated.

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

I'm not sure I understand what you are proposing. Who should define the corevocab? You as the application developer? We as JSON-LD community? Taking again "name" as an example. Is that FOAF's name or schema.org's?

Furthermore, how is that different from

{
  "@context": "http://example.org/corevocab.jsonld",
  "name": "Foo",
  "description": "Blah"
}

You can also just reference contexts by their IRI but of course that doesn't eliminate the requirement to actually define one.


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

No, they are dropped when a document is processed.


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

I'm still not 100% sure I understand the problem and your proposed solution. You'll always need to map terms to IRIs. If you call that mapping vocab or just a context doesn't matter. The question is who's responsible for that mapping. I think it should be the author of the data respectively the application in your case. Having a predefined built-in default context in JSON-LD causes much more problems than it solves IMHO.


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 24 May 2012 15:17:34 UTC