check cardinality of ORDER BY Criterion in extended search

[tobiasschweizer]

If the ORDER BY criterion is a property whose occurrence/cardinality is not 1, then the extended search logic does not work correctly.

The ORDER BY criterion has to be included in a GROUP BY statement, returning more than one row if property occurs more than once

-> only accept a value as an ORDER BY criterion if the property has a cardinality of exactly 1.

[tobiasschweizer]

also the statement binding the ORDER BY criterion must not be contained in an OPTIONAL or UNION. This makes sure that it is actually bound.

[tobiasschweizer]

@benjamingeer Would you like to do that in the type checker?

[tobiasschweizer]

@SepidehAlassi I think we would have to make beol:creationDate required (occurrence 1) to be able to support sorting of letters by date.

In case we do not have a date, we could put the whole century as a date. Do you think that would be ok?

[tobiasschweizer]

On the other hand, if an optional property is not inside an OPTIONAL or a UNION, the logic works fine. Resources, where the property is missing, are not returned though.

[benjamingeer]

If the ORDER BY criterion is a property whose occurrence/cardinality is not 1, then the extended search logic does not work correctly.

Why not?

Would you like to do that in the type checker?

The current type inspector doesn't have access to ontologies. I've been meaning to add another type inspector that would run as a second pass, querying ontologies to infer types, but that's non-trivial and I can't do it right away.

Does the search responder even have enough information to connect the ORDER BY variable with the property that points to it, and to the class that has a cardinality for that property? Looking at NonTriplestoreSpecificConstructToSelectTransformer.getOrderBy, it looks to me like we don't actually have that information. We just know the type of the variable itself, we have no idea what property or class it's associated with.

[benjamingeer]

Also, if you want the 'type' of a variable to include the cardinality of the property that points to the variable within a given class, then we will need to redesign what type inspection means. Currently, the type of a variable is just an IRI (a NonPropertyTypeInfo).

[tobiasschweizer]

If the ORDER BY criterion is a property whose occurrence/cardinality is not 1, then the extended search logic does not work correctly.
Why not?

Because we expect the order by variable to be bound in the response. Otherwise an error occurs.
Also if you have multiple occurrence of the same property, the same resource is repeated.

Actually this also means that you can only use order by when you are indicating a resource class. A property for itself has no cardinality.

I think this could be solved in the responder (we could get additional information from the ontology responder).

I've been meaning to add another type inspector that would run as a second pass, querying ontologies to infer types, but that's non-trivial and I can't do it right away.

Yes, I understand that this will be complex. If I find a fix for the problem mentioned above in the responder, this won't be urgent.