W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2019

Re: JSON-LD Framing

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 27 Feb 2019 12:24:41 -0800
Message-Id: <7E9B91E1-4ABB-4C54-AE9D-8B7D783281B5@greggkellogg.net>
Cc: Robert Sanderson <azaroth42@gmail.com>, Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>, Angelo Veltens <angelo.veltens@online.de>, Linked JSON <public-linked-json@w3.org>
To: Dave Longley <dlongley@digitalbazaar.com>
> On Feb 27, 2019, at 12:13 PM, Dave Longley <dlongley@digitalbazaar.com> wrote:
> 
> 
> On 2/27/19 2:59 PM, Gregg Kellogg wrote:
>>> On Feb 27, 2019, at 11:56 AM, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>
>>> <mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com>>> wrote:
>>> 
>>> 
>>> Ahh! I have been hit by this in the past. If the only distinguishing
>>> feature is the type, and then you want to subset that further by
>>> requiring additional properties (via require all), then that is not
>>> currently possible?
>>> 
>>> Is that a bug that we can fix in 1.1, or a feature?
>> 
>> It’s not a bug, per-se, as this is how it was designed (clearly, as
>> stated by the frame matching algorithm). However, I think we might be
>> able to improve this to better align with expectations when both @type
>> and properties (and @requireAll) are present. Dave?
> 
> Heh, I've been bitten by this myself. I recommend that when
> `@requireAll` is `true` and `@type` is present, that we actually require
> all of the properties or there is no match. Otherwise `@requireAll`
> seems to have no effect in the presence of `@type`.

What about when `@type` is combined with other properties and `@requireAll` is false? It could be interpreted to mean that either `@type` matches, or one of the other specified properties matches, which it doesn’t now.

I’m +1 for saying that `@requireAll` requires both `@type` and all other stated properties to be present (along with @id, if it’s there too).

Gregg

>> 
>> Gregg
>> 
>>> Rob
>>> 
>>> On Wed, Feb 27, 2019 at 11:50 AM Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>
>>> <mailto:gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>>> wrote:
>>> 
>>>>    On Feb 27, 2019, at 8:07 AM, Stian Soiland-Reyes
>>>>    <soiland-reyes@manchester.ac.uk <mailto:soiland-reyes@manchester.ac.uk>
>>>>    <mailto:soiland-reyes@manchester.ac.uk <mailto:soiland-reyes@manchester.ac.uk>>> wrote:
>>>> 
>>>>    On second thought I think this is a bug in the JSON-LD Playground as
>>>>    @requireAll should override that behavior as I described.
>>> 
>>>    It matches the specification text, but there is some room to
>>>    modify or improve this.
>>> 
>>>    Currently the Frame Matching Algorithm [1] says the following:
>>> 
>>>        In general, a node object matches a frame if it meets the
>>>        matches on |@type|, or |@id|, or if it matches given one of
>>>        several different properties (or all properties, if
>>>        the require all flag
>>>        <https://www.w3.org/TR/json-ld11-framing/#dfn-require-all-flag <https://www.w3.org/TR/json-ld11-framing/#dfn-require-all-flag>> is
>>>        present.).
>>> 
>>> 
>>>    Because `@type` is present, we match using that only. If neither
>>>    `@type` nor `@id` are present in the frame, matching is done on
>>>    properties. `@requireAll` does, indeed, require that all stated
>>>    properties be present to match, which happens if you remove
>>>    `@type`. Otherwise, if `@requireAll` is false, it matches on _any_
>>>    property present in the frame.
>>> 
>>>    Gregg
>>> 
>>>    [1] https://www.w3.org/TR/json-ld11-framing/#frame-matching <https://www.w3.org/TR/json-ld11-framing/#frame-matching>
>>> 
>>>>    On Wed, 27 Feb 2019 15:56:41 +0000, Stian Soiland-Reyes
>>>>    <soiland-reyes@manchester.ac.uk <mailto:soiland-reyes@manchester.ac.uk>
>>>>    <mailto:soiland-reyes@manchester.ac.uk <mailto:soiland-reyes@manchester.ac.uk>>> wrote:
>>>>>    The frames are matched on @type if that is provided, otherwise on
>>>>>    pattern.
>>>>> 
>>>>>    If you delete "@type": "Person" it will probably do what you
>>>>>    intend at
>>>>>    the risk of including other objects that have familyName and
>>>>>    givenName.
>>>>> 
>>>>>    On Wed, 27 Feb 2019 11:56:48 +0100, Angelo Veltens
>>>>>    <angelo.veltens@online.de <mailto:angelo.veltens@online.de> <mailto:angelo.veltens@online.de <mailto:angelo.veltens@online.de>>> wrote:
>>>>>>    Hi all, I have a question regarding framing.
>>>>>> 
>>>>>>    I have an input graph containing 2 Persons, and a frame for a
>>>>>>    Person
>>>>>>    with a specific givenName and familyName. (perma-link below)
>>>>>> 
>>>>>>    My expectation would be, that the result contains only the
>>>>>>    Person that
>>>>>>    matches the example frame, but in fact, I get both Persons,
>>>>>>    just that
>>>>>>    the Person, which does not match the frame has givenName and
>>>>>>    familyName
>>>>>>    set to null.
>>>>>> 
>>>>>>    Am I misunderstanding what framing is supposed to do?
>>>>>> 
>>>>>>    Here is what I am doing  as a perma-link to the playground:
>>>>>> 
>>>>>>    https://json-ld.org/playground/#startTab=tab-framed&json-ld=%7B%22%40context%22%3A%7B%22%40version%22%3A1.1%2C%22%40vocab%22%3A%22https%3A%2F%2Fschema.org%2F%22%7D%2C%22%40graph%22%3A%5B%7B%22%40id%22%3A%221%22%2C%22%40type%22%3A%22Person%22%2C%22name%22%3A%22John%20Doe%22%2C%22givenName%22%3A%22John%22%2C%22familyName%22%3A%22Doe%22%7D%2C%7B%22%40id%22%3A%222%22%2C%22%40type%22%3A%22Person%22%2C%22name%22%3A%22Jane%20Doe%22%2C%22givenName%22%3A%22Jane%22%7D%5D%7D&frame=%7B%22%40context%22%3A%7B%22%40version%22%3A1.1%2C%22%40vocab%22%3A%22https%3A%2F%2Fschema.org%2F%22%7D%2C%22%40type%22%3A%22Person%22%2C%22%40requireAll%22%3Atrue%2C%22givenName%22%3A%22John%22%2C%22familyName%22%3A%22Doe%22%7D&context=%7B%22%40context%22%3A%7B%22%40version%22%3A1.1%2C%22%40vocab%22%3A%22https%3A%2F%2Fschema.org%2F%22%7D%2C%22%40type%22%3A%22Person%22%2C%22%40requireAll%22%3Atrue%2C%22givenName%22%3A%22John%22%2C%22familyName%22%3A%22Doe%22%7D
>>>>>> 
>>>>>>    Thanks in advance!
>>>>>> 
>>>>>>    Kind regards,
>>>>>>    Angelo
>>>>>> 
>>>>>    Attachment: pEpkey.asc (application/pgp-keys)
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Rob Sanderson
>>> Semantic Architect
>>> The Getty Trust
>>> Los Angeles, CA 90049
>> 
> 
> 
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.
Received on Wednesday, 27 February 2019 20:25:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 February 2019 20:25:08 UTC