When executing a SPARQL query that takes inference rules into account, Virtuoso is producing unexpected results that do not include plain literal values. If I do not apply inference rules when performing the same query, the plain literal values are returned as expected. What's going on?
Result without Inference Rules:
<http://result/subject/1> <http://my/custom/ontology#hasName> "John"
Result with Inference Rules:
<http://result/subject/1> <http://my/custom/ontology#hasName> <iri_id_123456789_with_no_name_entry>
I did some searching around and couldn't find any information discussing what's causing this and how to fix it. By "fix" I mean produce the desired behavior of having plain literal values returned regardless of inference rules being applied.
Related
I am trying to perform a filter on a json:api endpoint.
?filter[name]=test name works fine if the name in db is exactly test name. But I want the server to return me values if name is Test name,tEst name or any other combination possible. How can I do this?
Thank you.
The JSON:API specification does not define the filter strategy:
JSON:API is agnostic about the strategies supported by a server. The filter query parameter can be used as the basis for any number of filtering strategies.
https://jsonapi.org/format/#fetching-filtering
It contains a recommendation for filtering strategy that matches your URL design:
It’s recommended that servers that wish to support filtering of a resource collection based upon associations do so by allowing query parameters that combine filter with the association name.
For example, the following is a request for all comments associated with a particular post:
GET /comments?filter[post]=1 HTTP/1.1
https://jsonapi.org/recommendations/#filtering
But even that recommendation does not cover what comparison operator should be used. It also doesn't cover if that should be case sensitive or not. It depends on the filtering strategy picked by the concrete implementation.
Please note that also a strategy encoding the comparison operator in the URL would be valid. E.g. you may encode the comparison operator in the query parameter like this:
GET /companies?filter[name][equalsCaseInsensitive]=test%20name
GET /companies?filter[name][equalsCaseSensitive]=test%20name
GET /companies?filter[sales][greaterThan]=100000
I added a new functionality to my application and now I'm getting this error:
maximum of 1000 expressions to evaluate has been reached
raised by firestore rules.
Because of it seems there are much less 1000 controls to be done for that specific write, I would like to ask some suggestions to avoid this behaviour or to introduce some vulnerabilities.
are logical expressions short-circuited?
what is defined as expression?
will this limit be extended?
Do you have any advice to avoid this problem?
Logical expression are short circuited.
An expression is anything that evaluates to some value. For example, true is one expression. false || false is three expressions.
There is no roadmap to change the limit. The limit is in place in order to prevent excessive resources being used by every operation. Bear in mind also that security rules are free (except for document access), and there is always going to be strict limits on what is provided for free.
Since we can't see your rules, it's not really possible to recommend exact advice. You should consider using functions to cut down on the number of expressions evaluated for some access. If you find yourself typing things like request.resource.data.foo a lot, consider using a function and pass request.resource.data to it to extract values rather than evaluating request.resource.data repeatedly, which is three expressions.
I'm designing an API to query the history of a value over a time period. Think about a temperature value, and you want to query all the values for today.
I have a from and a to parameter to specify the boundaries of the query.
The values available may not exactly match the boundaries requested. For example, if from is 2016-02-17T00:00:00Z, the first value may be on 2016-02-17T00:04:30Z. To fully represent a graph of the period, it is necessary to retrieve one more value outside the given range. The value on 2016-02-16T23:59:30Z is useful and it would be convenient for the user to not have to make another query to retrieve it.
So as the API designer I'm thinking about a parameter with a pair a of boolean values that would tell for each boundary: give me one more value if there is no value exactly on the boundary.
My question is how to name this parameter as English is not my native language.
Here are a few ideas I have so far but with which I'm not totally satisfied:
overflow=true,true
overstep=true,true
edges=true,true
I would also appreciate any links to existing APIs with that feature, either web API or in programming languages.
Is it possible to make this more of a function/RPC that a traditional rest resource endpoint, so rather than requesting data for a resource between 2 dates like
/myResource?from=x&to=x
something more like
/getGraphData?graphFrom=&graphTo=x
Whilst its only a naming thing, it makes it a bit more acceptable to retrieve results for a task wrapped with outer data, rather than violating parameters potentially giving unexpected or confusing results.
When needing to create a URL that takes a finite set of parameters, where all of said parameters are semantically the same "level", what is the current consensus around the use of delimiters within URLs? Here's an example:
/myresource/thing1,thing2,thing3
/myresource/thing2,thing1
/myresource/thing1;thing2;thing3
/myresource/thing1;thing3
That is to say, the parameter here could be a single, a pair or a triple. They can be specified in any order because they are not a logical tree, and thing2 is not a subordinate resource of thing1, so doing something like this seems "wrong":
/myresources/thing1/thing2/thing3
This bothers me because it implies a tree-like relationship between the elements of the triple, and that is not the case (despite many HTTP frameworks seemingly pushing this, wrongly in my view). In addition, using a query string doesn't feel right as this is not a search operation, it is a known triple in a very finite space - there's nothing to query or search, so to speak.
I suppose the other option would be to make it a POST request and supply a body that details the parts of the triple being supplied. This doesn't give me warm fuzzies though, for some reason.
How have others handled this? Delimiters seem clean to me, and communicate the intended semantics of the resource, but i know there are folks would would take a different view, and I was looking to understand the experiences of others who've had similar use cases.
Since any value can be missing and values can appear in any order, How would you know which value is for which parameter (if that matters).
I would have used query string for GET, or in the payload for POST.
Use query parameters
/path/to/the/resource?key1=value1&key2=value2&key3=value3
or matrix parameters
/path/to/the/resource;key1=value1;key2=value2;key3=value3
Without a proper example, I'm not sure exactly about your needs.
However, a little known fact is that any HTTP parameter can have multiple values. It is the way to go when you have a set of objects (see GoogleMaps static API for an example).
/path/to/the/resource?things=thing1&things=thing2&things=thing3
Then you can use the same API for single, pairs, triples (and more).
What parts of a SQLite statement are able to take bound parameters? For instance, I have discovered that the following is invalid:
SELECT #column1 FROM #table WHERE #column2 = #criteria
The only parameter in the example that I've been able to get to work properly is #criteria, leading me to think that only values on the right hand side of an equation can be bound as a parameter.
I'm having a hard time finding an answer for this in the official documentation on bound parameters and my searching on the internet, so could anybody please tell me definitively what parts of a SQLite statement can be bound?
That documentation says:
literals may be replaced by a parameter
A literal value is:
a constant of some kind. Literal values may be integers, floating point numbers, strings, BLOBs, or NULLs.
Table and column names are not strings (although SQLite sometimes allows you to use the same syntax for compatibility with MySQL).