- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Wed, 27 Feb 2019 15:13:31 -0500
- To: Gregg Kellogg <gregg@greggkellogg.net>, Robert Sanderson <azaroth42@gmail.com>
- Cc: Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>, Angelo Veltens <angelo.veltens@online.de>, Linked JSON <public-linked-json@w3.org>
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>> 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`. > > Gregg > >> Rob >> >> On Wed, Feb 27, 2019 at 11:50 AM Gregg Kellogg <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>> 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>> 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>> 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:14:01 UTC