Reformulate the 'type' parameter as another property

[wetneb]

Given that we are thinking about changing the query field of reconciliation queries into a property (#134), I think it's tempting to think whether we could do the same for types. It would then let us use the additional settings on properties (#131), essentially offering users the choice between:

• union of types (any)
• intersection of types (all)
• complement of the union (none)

One problem is that the property values we currently allow in a reconciliation query do not include type ids. I am not too sure what to do about this.

But overall I feel like #115 is likely going in the wrong direction, given the recurrent feedback we get in OpenRefine about needing support for reconciling against multiple types. (See the discussion in #109 too)

[thadguidry]

I think property values need to support the best practice of "Things not Strings". Now, there are a few ways to allow for that, and JSON-LD provides one way https://w3c.github.io/json-ld-bp/#things-not-strings along with several other best practices. In fact, once my eye heals, I'll be writing and hosting a service that uses JSON-LD to provide not only @context but also allow mappings via @vocab. I generally think at this point of the next draft we should take our time and see how to incorporate more JSON-LD to allow even more standardization and reuse, I.e. not Hydra as an interop example but instead JSON-LD and the Principles of Linked Data. I think eventually we could also publish a JSON-LD Context for standardization.