You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the TYPE keyword can be used to extract types only from nodes. In the case of a node like /u<paul> it would extract /u, for example.
But, as a feature request, it would be interesting to be able to extract "types" from predicates and literals as well, and also be able to use them in HAVING clauses to filter our results.
To illustrate, it would be nice that BQL supported queries such as:
SELECT ?s, ?p, ?o, ?o_type
FROM ?test
WHERE {
?s ?p ?o TYPE ?o_type
}
HAVING ?o_type = ^^type:float64;
On which it would understand that we want triples that have an object that is a literal, and that this literal is specifically a float64 literal.
In a similar way, we could use ^^type:int64 for int64 literals and ^^type:text for text literals, and so on.
For predicates, the HAVING clause could be:
HAVING ?o_type = ^^type:predicate;
(useful in the case of reification and blank nodes)
Or even:
HAVING ?o_type = ^^type:predicate:immutable;
To specifically query for immutable predicates. We could analogically use ^^type:predicate:temporal to specifically query for temporal predicates as well.
In the case of nodes, the HAVING clause could be:
HAVING ?o_type = ^^type:/u;
If we wanted only node objects with type /u (the users in our database).
This feature would be useful in a number of scenarios, as illustrated.
Also, for coherence, it is important to remember that, in SELECT queries, the result for TYPE bindings should also follow the same pattern as above. To illustrate, the query:
SELECT ?o, ?o_type
FROM ?test
WHERE {
?s ?p ?o TYPE ?o_type
};
Thanks for putting this explanation together @rogerlucena. I was wondering if you have settled on using = vs the is,covariant, contravariant combo alternatives for the comparison primitives.
Following Xavier's comment, an alternative to using = is implementing a is keyword to be used when comparing types. For example:
HAVING ?o_type is ^^type:predicate:immutable;
In the case of TYPE bindings for nodes, it would also be possible to implement the covariant and contravariant keywords to unlock the use of the hierarchies that are intrinsic of node types (such as /country/corp and /country/corp/employee). This could be helpful for allowing more ellaborate comparisons inside HAVING clauses, an alternative for what was requested with #122.
Currently, the TYPE keyword can be used to extract types only from nodes. In the case of a node like
/u<paul>
it would extract/u
, for example.But, as a feature request, it would be interesting to be able to extract "types" from predicates and literals as well, and also be able to use them in HAVING clauses to filter our results.
To illustrate, it would be nice that BQL supported queries such as:
On which it would understand that we want triples that have an object that is a literal, and that this literal is specifically a
float64
literal.In a similar way, we could use
^^type:int64
forint64
literals and^^type:text
fortext
literals, and so on.For predicates, the HAVING clause could be:
(useful in the case of reification and blank nodes)
Or even:
To specifically query for immutable predicates. We could analogically use
^^type:predicate:temporal
to specifically query for temporal predicates as well.In the case of nodes, the HAVING clause could be:
If we wanted only node objects with type
/u
(the users in our database).This feature would be useful in a number of scenarios, as illustrated.
Also, for coherence, it is important to remember that, in SELECT queries, the result for TYPE bindings should also follow the same pattern as above. To illustrate, the query:
Should now return something like:
For consistency.
The text was updated successfully, but these errors were encountered: