Re: A use case for @vocab?

Hi Markus, Gregg,

On Thu, May 24, 2012 at 5:16 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> 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.

Will do. I have yet to go into the details of the different
possibilities, but framing is indeed probably what I need in the end,
thanks.


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

At the generation stage, I don't need the API to know what I mean by
"name". I need it to know that "http://example.org/corevocab#name"
maps to a "name" property. But I'd rather say that anything that
starts with "http://example.org/corevocab#" maps to a prefix-less
property.


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

For nothing in the sense that the application only really needs the
@context to generate the JSON-LD. It's not really going to make use of
that @context elsewhere.


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

"Documenting" is certainly good practice but it also means two non
related portions of code need to be kept in sync. That's error prone.
Spotting that a property is missing from the context would not be too
hard, but that would still require a bit of time in debug mode to
detect that the expected "yihaa" property is actually still named
"http://example.org/corevocab#yihaa", which explains why the code
fails to render its value. On the other hand, it's not a big deal if
the object contains additional properties around, and it's also better
from a debug perspective (using a code inspector) if these additional
properties can have short names.

As Josh raised in his reply, an empty prefix with no colon is
preferable in JavaScript where developers often prefer to access
properties using the dotted notation "item.name". That's not required,
just easier for most JavaScript developers I interact with.


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

In the example, "name" would be "http://example.org/corevocab#".
In a real-life example, "name" would be "http://schema.org/name" if
the page the JSON-LD structure is generated from follows schema.org
conventions. That's up to the author of the content. I'm not trying to
introduce any additional vocabulary or to have the JSON-LD community
endorse any kind of vocabulary.


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

It's different from a *generation* perspective. If I use an external
context, I take it that the framing/compaction algorithm would
actually need to retrieve it, so the net result is actually worse for
my client-side app in terms of network usage and latency.



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

OK, thanks for the confirmation.

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

Hopefully the above clarifies that it's the mapping from IRIs to terms
that I'm more interested in. The mapping from terms to IRIs would
actually be straightforward as well.

Francois.


>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Thursday, 24 May 2012 16:51:46 UTC