Rename the Geohash.php script with a capital first letter to fix an issue with autoloading.
Creation of a new "source interface" layer for each of the endpoints.

A "source interface" is a block of code that is executed if a valid query has been
sent to any web service endpoint of the framework. This "block of code" is what define
the behavior of a endpoint. This code will check what are the parameters requested
by the user, then will generate a query, or a series of queries, to one or multiple
data management systems. Then this block of code will get back all the result(s) that
matches the query(ies) and will populate the "rset" (resultset) object of the web service
endpoint. It is the content of the rset object that will be used by the web service endpoint
to serialize the resultset to be returned to the requester.

There are two different kind of source interfaces:

  (1) Source interfaces that return a resultset. The returned resultset is a set of one, or
      multiple records' descriptions. Such a source interface could be querying the Solr
      web service endpoint for the Crud: Read or Search web service endpoints.
  (2) Source interfaces that perform some action within structWSF but that doesn't return any
      resultset. Such a source interface could create a new record in Virtyoso & Solr such as
      the Crud: Create web service endpoint.

Each web service endpoint in the structWSF framework has a DefaultSourceInterface defined.
This default source interface is the default behavior of each web service endpoint. The
behavior of a web service endpoint can be modified by creating new source interfaces.
  *
  * In the implementation of a SourceInterface, all variables are accessible via the "$this->ws" object.
  * This object is a reference to the web service instance that uses this source interface.
Remove unnecessary comments
Added a new versioning mechanism to the framework. In this versioning system, two different things got its own version:

  (1) the Web Service endpoints API
  (2) the Sources Interfaces

The goal of the versioning system is to notice the user of the endpoint if
the behavior of the endpoint changed since the client application was developed
for interacting with it.

The version will increase when the behavior of the source interface changes. The
behavior may changes if:

  (1) A bug get fixed (and at least a behavior changes)
  (2) The code get refactored (and at least a behavior changes) [impacts]
  (3) A new parameter/feature is added to the endpoint (but at least another behavior changed) [impacts]
  (4) An existing parameter/feature got changed [impacts]
  (5) An existing parameter/feature got removed [impacts]

In this kind of versioning system, versions are not backward compatible. Because
the version only changes when core behaviors of existing features changes, the
versions can't be backward compatible. It is used to track if behaviors changed,
and to notice users if they did since they last implemented the API.

Also, for the custom source interfaces, if the API of an web service endpoint changed, but
that the source interface hasn't been upgrade to communicate with it, then an error will
be reported as well.
Fixe issues related to the refactorization of the code with the new interfaces mechanism.
(1) Removed unused variables.
(2) Added missing $requestedInterfaceVersion parameter.
Missing namespaces references
Issue with a reference to an unexisting parent method. This issue has been introduced with the latest code refactoring.
Handle the datatypes defined as a range of a property.
Make sure to add the target domain and range when generating the property hierarchy serialization file.
Fix an issue with the xmlEncode() function across structWSF's code. The problem was that the encoding of "\" was not a XML reserved character.
Then, when the PHP XML parser was parsing this, then the character was kept encoded which was leading to unserialization() errors because of
the namespaces that are using this character.
In the coming version of structWSF, we won't make a distinction between the Solr schema that has geo-related information and not. Everything will be defined in the same
schema. Also, all the future versions of structWSF will be installed such that they are geo-locable. This means that we won't have the option to make a structWSF
instance geo-enabled or not. All of them will be. Also, in the next version of structWSF, Solr version 3.6 will be used.

This new schema take these facts into account. Also, this new schmea does include 3 news fields to handle three new different datatypes:

(1) date
(2) int
(3) float
The Geohash class is not used anymore. With the usage of Solr 3.6 and the SOLR-2155 plugin, we don't need it anymore since the geohash is
automatically computed by the SOLR-2155 pluing at indexation time.
(1) Removed the addition of the lat_rad and long_rad in Crud: Create & Crud: Update
(2) Added the new way to add geo-located data for solr 3.6 and the SOLR-2155 plugin
(3) Added datatype handling in crud create & update for the 4 basic datatypes: literal, date, int and float.
    The datatype to use is the one defined in the ontologies loaded in this instance.
(4) Properly handled the datatype range definition when we are saving datatype properties with datatype ranges.
(5) Added date, int and float range filters when performing attribute/value filtering.
Support of multiple languages across structWSF:

(1) A new setting in network.ini to list all the supported languages by the structWSF instance
(2) Crud: Create and Crud: Update now index language related information
(3) Search, Crud: Read and Ontology: Read now return records description according to a specified language at query time
New version of the Solr 3.6 schema that enables multiple-languages in structWSF.

For each new language you add to the network.ini configuration file, you will have to duplicate all the language related fields with the language identifier.
Fix a misnamed Solr field that was causing an indexation error when using reification statements.
Fix an issue with xmlEncode() related to the array of things to search and things to replacce.
Fix an issue with xmlEncoded() which was related to the number of things to search for, and the number of things to replace with. Same issue as the one in WebService.php
Validate that safeDate() doesn't return an empty date. This was causing issues with Solr when we were committing empty date string.