type_strict option should be exposed in reconciliation UI

[wetneb]

When configuring a reconciliation, we could let users decide if type matching is strict or loose. There is already a "type_strict" parameter in the specs but it isn't exposed in the UI and we are not sure what the original meaning of this option was.

See wetneb/openrefine-wikibase#4

[thadguidry]

I remembered what it does...

any - At least 1 type in query must be present on the entity in the graph for it to be returned

all - All types in query must be present on the entity in the graph for it to be returned

should - i think this was a 50% rule where at least 50% or more of the types must be present on the entity in the graph for it to be returned. (say an entity has 4 types in graph, and query is type_strict providing 2 of the types, but entity will not be returned since not 50% of types, but of providing 3 of the types present on the entity, then it would be returned - 75% of types matching)

[wetneb]

okay, so that assumes we let the user choose multiple types, which isn't currently possible

[thadguidry]

@wetneb right, its support was for multiple types.

[wetneb]

Adding the reconciliation API design tag because the semantics of this parameter are not fully known and we might want to rethink how this is expected to work before implementing in the client (OpenRefine).

[tfmorris]

I think should (which is what's used by the code) means use the list of types for scoring, but not as a hard filter. I don't think there's any specific threshold (50% or any other).

[tfmorris]

Actually, the original Freebase Suggest API documentation is available on archive.org and it says:

type_strict | String | Default: "any"

This parameter makes it possible to control how specific the type matches must be. A value of "should" gives preference to matches by boosting their query score but doesn't require any, "any" requests that at least one type value matches and "all" requires that all types match.

[thadguidry]

@tfmorris Sorry, I should have updated this issue after I found the info 3 years ago. Actually, I did eventually remember that Andi Vajda and I documented on the Freebase Wiki very well and had to use my email search to find what it was called, "filter constraints".... that eventually got translated into the official API docs... It's combining behavior is documented here (scroll down just a bit):
https://developers.google.com/freebase/v1/search-overview#advanced-filtering

The Search API supports a large number of filter constraints to better aim the search at the correct entities.

For example, using a "type" filter constraint, we can show a list of the most notable people in Freebase.

filter=(any type:/people/person)

Filter constraints accept a variety of inputs:

• Human readable IDs for schema entities or users, for example:
  • /people/person for a type constraint
  • /film for a domain constraint
• Freebase MIDs, for example:
  • /m/04kr for the same /people/person type constraint
  • /m/010s for the above /film domain constraint
• Entity names, for example:
  • "person" for a less precise /people/person type constraint
  • "film" for a less precise /film domain constraint

Filter constraints can be classified into a few categories. See the Search Cookbook for more details.

Filter constraints can be freely combined and repeated in the SearchRequest directly. Repeated filter constraint parameters are combined into an OR query. Different filter constraint parameters or groups are combined into an AND query.

For example:

To search for "people or cities named Gore", try:

query=gore
&filter=(any type:/people/person type:/location/citytown)

This combining behavior can be overriden and better controlled with the filter parameter which offers a richer interface to combining constraints. It is an s-expression, possibly arbitrarily nested, where the operator is one of:

• any, logically an OR
• all, logically an AND
• not
• should, which can only be used at the top level and which denotes that the constraint is optional. During scoring, matches that don't match optional constraints have their score divided in half for each optional constraint they don't match.

For example:

To match on the /people/person type or the /film domain, try:

query=gore
&filter=(any type:/people/person domain:/film)

[wetneb]

@tfmorris thanks a lot for this fantastic archeological finding! It could be worth adding this to the reconciliation API specs (both in 0.1 and current draft).

[wetneb]

The type_strict attribute was removed from the specs, so I don't think it's worth exposing it:
reconciliation-api/specs#115
I would therefore close this issue.