Re: JSON-LD Framing

On 2/27/19 3:24 PM, Gregg Kellogg wrote:
>> On Feb 27, 2019, at 12:13 PM, Dave Longley <dlongley@digitalbazaar.com
>> <mailto: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>> 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.

Well, we've had `@type` OR duck-type matching since the beginning --
where the presence (or absence) of `@type` determines which to use. If
there are use cases where we need to allow `@type` to be treated like
other properties (not special), we should probably introduce another
option like `@ducktype: true` (bikeshed).

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

+1

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


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Wednesday, 27 February 2019 20:52:25 UTC