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
Sometimes, the matches "collide" with themselves, which is not necessarily a problem but in the interface it may be confusing.
For example, when I run the query
h1:[rstr h2]
h3:[]
It's possible that h1 matches with the same predication as h3. When it doesn't it, it is displayed as expected:
When it collides, one example is like that:
Maybe there should be a color change when there is more than one match in a predicate.
The text was updated successfully, but these errors were encountered:
We may need to expose the project to DELPH-IN members to have feedbacks. See delph-in/docs#24
In the meantime, I believe we have two questions here:
do we want that h3: [] denote any predication? Because h:[* x] is a predication with hole h with an argument with x as value... so if we omit the pattern inside the brackets we are saying anything? So what is the denotation of the empty string as a query?
different variables may have the same bind or not? If I have h1 and h2, do we adopt the standard FOL semantics where they can both point to the same individual or we adopt a more practical approach were different variables should not have the same bind... what is the SPARQL semantics for that? I need to double-check.
Sometimes, the matches "collide" with themselves, which is not necessarily a problem but in the interface it may be confusing.
For example, when I run the query
It's possible that
h1
matches with the same predication ash3
. When it doesn't it, it is displayed as expected:When it collides, one example is like that:
Maybe there should be a color change when there is more than one match in a predicate.
The text was updated successfully, but these errors were encountered: