Introduce "properties_strict" for strictness of attributes that must be present

[thadguidry]

As I mentioned in PR #23 I think there might be a need to introduce something similar to the existing type_strict but for properties.

I think this is useful to note to implementers. This also exposes a need to possibly add a new parameter for 'properties_strict' (like type_strict) where the value might be "must" or "should" and would offer a slightly different score?

This would be a setting that controls the results returned as well as possibly the scoring of returned results. (but maybe there should be 2 settings here for each, dunno) SQL's WHERE clause is always STRICT in a sense. But Clients of reconciliation services might not always want to be STRICT in handling properties and still want to return results depending on a setting:

• some of the properties must match ( "properties_strict":"should" )

• all the properties must match ( "properties_strict":"must" )

And have some expectation on scoring based on one setting or the other. Thoughts on either results returning, or scoring?

[VladimirAlexiev]

@thadguidry You describe this option as acting on the array of props. But I think more nuanced cases are needed:

• In most cases I think it should apply to individual props. Eg "Country is must, city is should"
• In some cases props should match together, eg "Latitude and Longitude must match together, if only one of them matches that doesn't count as a match"
• I think the cases where the option acts on all props globally are very rare: usually some props are more important than others.

In addition:

• we need to clarify the semantics of type_strict, I'll open a separate issue
• I think it makes sense to score types and props in a unified manner, because types are very similar to props (just like rdf:type is nothing more than just another RDF props). So I think the two options should act together (or be one option)

[fsteeg]

Is this resolved with the new conditions, match_quantifier, and match_qualifier?

See https://reconciliation-api.github.io/specs/draft/#structure-of-a-reconciliation-query

[thadguidry]

@fsteeg Yes, I think this issue should be resolved now that we have those generically to handle not only narrow but also broad and diverse conditional ways to match values. I'd be in favor of closing this issue for that reason.

[thadguidry]

@fsteeg Yes, I think this issue should be resolved now that we have those generically to handle not only narrow but also broad and diverse conditional ways to match values. I'd be in favor of closing this issue for that reason.