W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2016

Re: JSON-LD & nested structure

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Wed, 3 Aug 2016 09:55:59 -0400
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: Aymeric Brisse <aymeric.brisse@gmail.com>, public-linked-json@w3.org
Message-ID: <762b2b4b-f069-d88f-616b-ae9710b85412@digitalbazaar.com>
On 08/02/2016 03:47 PM, Gregg Kellogg wrote:
>> On Jul 29, 2016, at 9:04 AM, Dave Longley
>> <dlongley@digitalbazaar.com> wrote:
>>
>> On 07/29/2016 11:55 AM, Aymeric Brisse wrote:
>>> @Gregg : I cannot assume that the property will only be used by
>>> the top-level element.
>>>
>>> @Dave : already tried it but it doesn't work
>>
>> I modified Gregg's example and it worked for me:
>>
>> http://json-ld.org/playground/#/gist/bd569269ce69a8fe7ecebde0713acc73
>
>>
> Dave, I do have the support for supporting value matching on @id,
> but the reason this doesn’t work for me is that when the frame is
> expanded, it returns an empty array, rather than one containing on
> object with the expanded @id. If you take the frame from the
> playground link and expand it, you’ll get the same thing. Yet, when
> used for framing, your processor seems to act as if the frame is not
> empty.

The JavaScript processor has an option `keepFreeFloatingNodes` that it
sets to `true` prior to expanding a frame. Frames need a few special
rules applied during expansion in order to preserve the user's intent in
the output:

https://github.com/digitalbazaar/jsonld.js/blob/master/js/jsonld.js#L558-L559

You'll see there is also an `isFrame` option there that is later used to
ensure that an error is not thrown if `@id` is used with an `object`
value instead of a `string`. This allows people to construct frames to
select something that has an `@id` property without needing to
specify its value; of course, you can also specify it like we do in the
case at hand.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com
Received on Wednesday, 3 August 2016 13:58:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:48 UTC