- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Sun, 29 Jul 2012 20:08:06 -0400
- To: Lin Clark <lin.w.clark@gmail.com>
- CC: "public-linked-json@w3.org" <public-linked-json@w3.org>
On Jul 29, 2012, at 2:35 PM, Lin Clark wrote: > Hi all, Hi Lin, > First off, thanks so much to everyone for their help in figuring out how JSON-LD can work for Drupal's services initiative. > > I wrote up an explanation of the JSON-LD features that we'll be using... it's meant in part as an introduction to basic Linked Data concepts as they are used in JSON-LD, since there are very few Drupal devs who have any knowledge of LD. But I also cover two parts of the spec that we need which are still under development. > > The most important of these for our use case is language version handling. I explain both named graphs and language maps as possible ways to handle language versions. However, I do not feel comfortable moving forward with named graphs because I believe it is too much of a Linked Data specific concept, and the increased complexity would limit the number of people who could maintain this part of Drupal. I agree; named graphs are intended for a narrow use-case where statements need to be made about a graph itself, such as defining a signature. They may also be useful for dump formats, similar to N-Quads and TriG. Not intended for normal markup. > I think that Niklas L's latest proposal for language maps would fit our use case without adding too much conceptual overhead. Specifically, I would envision something like this snippet: http://pastebin.com/zeHz1CG7 > > I was wondering what the current thinking on (and support for) the language maps proposal is? The group has agreed in concept to the use of language maps (see [1]). In principle, I support Niklas' design, but it probably needs to be talked through further (and implemented, of course). The main complication comes when compacting, and if such maps are automatically applied. I'm increasingly coming to the opinion that complex syntactic expressions are best done using domain-knowledge, and shouldn't be done automatically. The compaction algorithm should restrict itself to term substitution and relatively simple value compaction, without getting into the current complexity of splitting values between different keys based on appropriate match to the definition of each term. This might include automatic application of language- and id- maps, but maybe not. I think we need to find ways to make the core algorithms simpler. Gregg [1] http://json-ld.org/minutes/2012-07-03/ > Cheers, > Lin > > -- > Lin Clark > Drupal Consultant > > lin-clark.com > twitter.com/linclark >
Received on Monday, 30 July 2012 00:09:02 UTC