Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand support of TYPE extraction for literals and predicates too, in addition to nodes #124

Open
rogerlucena opened this issue Jul 31, 2020 · 2 comments

Comments

@rogerlucena
Copy link
Contributor

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
};

Should now return something like:

Result:
?o			?o_type
/u<paul>		^^type:/u
"3.7"^^type:float64	^^type:float64
"hello"^^type:text    	^^type:text
"parent_of"[]    	^^type:predicate:immutable 	

For consistency.

@xllora
Copy link
Member

xllora commented Jul 31, 2020

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.

@rogerlucena
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants