most_likely_tagsets should return classes, not strings

[epaulson]

It'd be nice if the most_likely_tagset call returned actual RDFlib objects instead of just a list of strings so we could figure out the classes involved, (though maybe it's easy to go from the strings to classes?)

The use case is in the recon API, after we predict the class for a query, in the protocol response we need to set an extra 'type' field. (For our use case, that's a bit redundant since we're actually predicting a type, but the protocol specs it, because there are other use cases where it's matching actual entities so an additional type field is useful in the response.) And because it doesn't usually matter, for type we just put back in whatever type the client asked to reconcile against, e.g. 'EquipmentClass', 'PointClass', or 'BrickClass', and default to BrickClass. Because we just get back a string like "Air_Flow_Pressure_Sensor" we can't do anything better, like look up the superclass of 'Air_Flow_Pressure_Sensor' and return that.

The bummer here is that OpenRefine doesn't actually use 'manifest' of possible types to decide what types to display to the user to reconcile against - OpenRefine, even before you officially start 'reconciling', just sends over a sample of a couple of rows to the server to see what types it gets back, and presents them as the list of possible types. This is wrong and a bug in OpenRefine - but it hurts Brick specifically, because obviously OpenRefine is sending these 'prequery' queries without specifying a type, which in our implementation means we reply back saying they're of type 'BrickClass', and hence the only possible type option OpenRefine displays for the real reconciliation process is 'BrickClass'.

Hopefully OpenRefine will fix its limitation and look at the manifest instead of trying to sample what types are possible, but one thing we could do is look at the type we predict and figure out its superclass.