In some cases, the procedure was adding a "fq= AND" which was not a valid Solr query. So we post-clean that usecase.
In the last code-refactoring, we forgot to add the last subject before returning the resultset. So, if you were getting 10 records from a query, only 9 were returned. If you were getting 1 record, none were returned.
Fixing an issue that appeared with the last code refactoring activity. The getAnnotationInfo() function was not returning the type array key, so the annotations that had a URI as object were not returned because they were ignored. So we now check if the "uri" key is defined for the $info array.
Depending on the context, some inferred parent classes URI may have been duplicated in the Solr index. It had no impact on any behavior except that it was taking more space in the index. This fix does take care not to duplicate any inferred parent classes in the Solr index.
Fix an issue with the usage of the Solr() construct. The last parameter was not specified in any calls, so the default parameter's value was used for the location of the folder of the fieldsIndex.srz file. This means that if the fields_index_folder was not /tmp/ in data.ini, then the fieldsIndex was not accessible by these services and may have lead to weird behaviors in some usecases.
Make sure that the Sparql endpoint only add the dcterms:isPartOf predicate if it is not already describing the record(s) we are about to return.
Missing an array declaration that was throwing an exception. This was causing certain getNamedIndividuals queries to die if the "descriptions" mode was used. This is an error that appeared with version 1.0a94.
Creation of a CSV value escaping function to escape the CSV values used in the generation of a commON file to export.
Modify the createOrUpdateEntity Ontology: Update web service call to modify an ontology's annotations if an ontology's description is given as input to this function.

Note: if you re-define an ontology's annotations, *all* the annotations currently defined for an ontology will be replaced by the ones provided in input. Also, the "advancedIndexation" parameter is not effective when an ontology's description is being updated.
Added the geo:locatedIn data in the resultset. This core Solr property was not added to the returned resultset.
Fixed an issue with the object properties returned by the endpoint. That issue has been created with the latest major code-refactoring activity in version 1.0a94
When updating a named individual in the ontology (OWLAPI), we have to make sure to drop all the statements where the value has multiple lines such as:

DataPropertyAssertion(skos:note <http://purl.org/ontology/peg/framework#Energy> "Energy
more text here...
more text here...
"^^xsd:string)

With the previous set of regex rules, this was not matched, and so was re-included after the deletion. The end result is that some triple where supposed to get deleted in the update process, and they were not.
Make sure that the OWLAPI ontology object is loaded. Even if it is not, we continue to try to delete the dataset in Solr and Virtuoso in case that the ontology is not loaded, un-loadable, and that the other data instances needs to be cleaned-up.
(1) Fix a bug in the Ontology Read endpoint that was not properly using the new internal resultset structure. The end result was that in some cases, an object value was not returned, because not existing.

(2) Properly handling the iron:allowedValue such that it gets properly serialized in irON.
Take care not to duplicate URIs of accessible dataset.
Modification of the internal Resultset array structure to add one more categorization layer: the dataset. Now the resultset is defined as:

                     Array("dataset-uri" =>
                       Array("record-uri" =>
                        Array(
                          "type" => Array(URIs...),
                          "prefLabel" => "preferred label",
                          "altLabel" => Array(alternative label literals...),
                          "prefURL" => "http://preferred-url.com",
                          "description" => "some description of the record",

                          "other-data-attribute-uri" => Array(
                            Array(
                              "value" => "some value",
                              "lang" => "language string of the value",
                              "type" => "type of the value"
                            ),
                            Array(
                              ...
                            )
                          ),
                          "more-data-attribute-uri": ...,

                          "other-object-attribute-uri" => Array(
                            Array(
                              "uri" => "some uri",
                              "type" => "optional type of the referenced URI",
                              "reify" => Array(
                                "reification-attribute-uri" => Array("value of the reification statement"),
                                "more-reification-attribute-uri" => ...
                              )
                            ),
                            Array(
                              ...
                            )
                          )
                          "more-object-attribute-uri": ...
                        ),

                        "more-record-uri": ...
                      )
                    )

That way, if two records, in two different datasets, have the same URI, they will be part of the serialized datasets (in xml, json, etc). Prior this upgrade, the Search endpoint was only returning a single record instead of two (one in each dataset).
(1) removed unnecessary code.

(2) Updated the code to use the new Resutlset structure (so, to define the dataset provenance of each result that got found with this search query).
properly defining the resultset array using the new internal array structure (the one that includes the dataset)
Upgrading the code to comply with the new internal Resultset structure: the one that adds the dataset provenance. In this case, the dataset provenance of what is returned by the Ontology Read endpoint is the queried ontology URI.
Only do the Authentication test of the $registered_ip variable if $registered_ip != $requester_ip

This removes an authentication test for most of the queries, and so make the endpoint more performing.