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.

[D-Groenewegen]

Thanks for raising this question because perhaps the specifications could be clearer on the functional requirements and options of 'types'. Should a 'type' always rely on the use of properties? Alternatively, should the 'properties' field allow for 'pseudo-properties' to accommodate types that work a little differently?

To clarify, I am currently in a situation with MediaWiki and Semantic MediaWiki where I aim to support three different kinds of 'types', which requires the system to know or recognise which of these is intended. In addition to the property-based approach using either 'things or strings', there are also categories (https://www.mediawiki.org/wiki/Help:Categories) and concepts (https://www.semantic-mediawiki.org/wiki/Help:Concepts).

Back to the reconciliation query. If I had to declare a concept or category under 'properties' rather than 'type', what to do with 'pid'? I could probably go for 'pseudo-properties', special-purpose identifiers, that tell the system internally which kind of 'type' to handle. Arguably, that approach would be slightly more transparent than using the 'type' field. Because categories and concepts come with so-called namespace prefixes (e.g. Category:People, Concept:People), it should be easy to tell them apart, multilinguality issues aside, but other systems may not offer that luxury.

[Edit] P.S. I realise that at the level of abstraction at which the specs are operating, it matters little whether the properties of the providing system are really semantic properties in the formal sense. I just wanted to highlight that 'type' could be ambiguous and that the proposed change could help differentiate between different kinds of types.

[wetneb]

Should a 'type' always rely on the use of properties?

At the moment (in the 0.2 specs and still in the current draft), the "types" and "properties" are two different concepts. So you can use types without using properties, and the other way around.

Alternatively, should the 'properties' field allow for 'pseudo-properties' to accommodate types that work a little differently?

At the moment, you can generate pseudo-properties that mirror types, but you don't have to.

If I had to declare a concept or category under 'properties' rather than 'type', what to do with 'pid'?

You would just pick a particular pid which would be able to tell your reconciliation service that the value supplied is to be understood as a type. For instance:

{
    "pid": "category",
    "v": "Category:My_category"
}

(if your type system consists of MediaWiki categories).

You could do that for multiple "type systems": one pid for categories, one for namespaces, and so on.

[D-Groenewegen]

Thanks, it makes sense to follow that approach. In fact, I've now built in the possibility for users to use properties instead of types to achieve the same thing. Both approaches are working for me on the test bench.