- From: François Daoust <francois@joshfire.com>
- Date: Thu, 24 May 2012 19:11:50 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: Josh Mandel <Joshua.Mandel@childrens.harvard.edu>, Linked JSON <public-linked-json@w3.org>
Hi Markus, Josh, Gregg, On Thu, May 24, 2012 at 6:38 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: >> I think François is advocating for `@vocab` for the same >> reason we have prefixes: to avoid having to explicitly define >> *every* predicate with the same prefix. (It's not "built-in," >> it's established in a context.) The special thing about >> `@vocab` is to establish an *empty* prefix, with no colon. >> And this might sound trivial (?), but colons make property >> names really annoying to work with in JavaScript. >> >> E.g. with @vocab the SMART context could be ~1k instead of 16k > > Oh sorry.. then I completely misunderstood his mail. Dammit. And I thought I was clear ;) Thanks for the clarification Josh, that is indeed what I meant. See my previous email. >> "Alert": { >> "@id": "http://smartplatforms.org/terms#Alert" > > You know that you can use prefixes in the context as well!? Something like > > { > "@context": { > "spt": "http://smartplatforms.org/terms#", > "Alert": "spt:Alert", > ... > }, > .. data (not using prefix) .. > } > > > I'm still not convinced that @vocab would be a good idea.. there are many > ways to solve this in an application but of course it depends on the > application's specific requirements. Hmm, I can only think of 2 main ways: 1. list properties in the @context. 2. parse the created JSON-LD before running the framing algorithm to create the @context on-the-fly; or use a specific implementation framing algorithm that makes certain assumptions on the @context That's why I propose @vocab as a third possible way. Now I agree that introducing new ways of doing something is not necessarily a good thing. Best, Francois. > > > -- > Markus Lanthaler > @markuslanthaler >
Received on Thursday, 24 May 2012 17:12:24 UTC