- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Wed, 27 Feb 2019 12:24:41 -0800
- To: Dave Longley <dlongley@digitalbazaar.com>
- 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>
- Message-Id: <7E9B91E1-4ABB-4C54-AE9D-8B7D783281B5@greggkellogg.net>
> 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