Fixed permissions checking issue. Was using 'administer construct' instead of 'administer construct ontology'.

Display an error message when the user tries to access structOntology without having access to the proxy service.

Update the getSubClasses() method such that if the class is not defined in the classes structure that at least it is specified as being a sub-class-of owl:Thing.

(1) create a new table "structfieldstorage_revisions_binding" to track the correspondence between internal drupal timestamp, and structWSF revisioning URIs
(2) Change how loading, deletation and creation of revisions works with this new table
(3) implements hook_revisionapi() to handle when revisions get published/unpublished

(2) Fix an issue that was adding an empty datasets filter parameter if no datasets were selected

Fix an issue with the number of the returned results in the search section of structOntology. The issue was that the aggregates, which are not displayed, were part of these numbers, so the numbering of the displayed results was not starting at 0.

Implementing the basic, default, entities revisioning system into the structFieldStorage module. We can now create and delete revisions for the fields that are saved into structWSF.

We also added a new setting to be able to map all the fields, including the ones that doesn't use the structfieldstorage storage type. This new setting is used in a data migration workflow.

Sometime, if an entity was not properly saved, then CRUD: Update was used on a non existing structWSF resource. If this usecase is detected, then CRUD: Create will be use instead to create the initial version of the record.

Re-enable the feature that shows the add new field field_sql_storage if the default field storage system defined in Drupal is not structfielstorage.

Make sure that if an owl:ObjectProperty is used, that we properly serialize the RDF that is getting saved in the CCR. We are not referring to a URI and not and literal.

Change the behavior of the RDF MAPPING section. Now, if the field type/widget is referring to another entity, then we will autocomplete on the list of owl:ObjectProperty from the ontologies. Otherwise, we will continue to display owl:DatatypeProperty and owl:AnnotationProperty to them.

The current field types/widgets that uses object properties are:

 (1) entityreference
 (2) Text with the struct_lookup_field widget
 (3) Text with the struct_lookup_field_with_scones_suggest widget

 * number_decimal
 * datestamp
 * date
 * datetime
 * list_boolean
 * entityreference

(1) Modified structFieldStorage to reify the internal Drupal value with the RDF value of the mapped property
(2) Handling new field types and field widgets: link_field, list_integer, number_integer, number_float, list_float, image and file.

If the widget that is used is list_float, then the value type is xsd:float

 (1) there is a new "add new field" section that will create a new field for the structfieldstorage field storage type
 (2) if the default field storage system is not structfieldstorage, then we add a section for these fields creation as well
 (3) we only display the field type and widget types that are known to be working with structFieldStorage when that field storage system is being used

Overall this update gives more flexibility to the creation and management of the content types per field storage system!

(1) direct the user to structOntology from the RDF MAPPING section to create new properties if required
(2) in the RDF MAPPING section, only return Annotation & Datatype properties to the user for now since there is no mechanism to create URIs from the Content Type forms for now

Check to make sure that all the fields using the structfieldstorage field storage system are mapped to a RDF property. If it is not the case for one or multiple fields, than errors are returned to give the opportunity to the user the map them before saving.

(1) added a new setting to define what should be the default field storage system when a new field is being created.
(2) Implement hook_form_alter() to add a new "STORAGE TYPE" column in the field overview table. It shows what is the field storage system used by a given field.

Make sure that if structFieldStorage is disabled, that we revert the default field storage system to the default one: field_sql_storage

Implement the Cron API along with the Cron Job schedeling API for running the synchronization everytime Cron is called.

Creation of the two synchronization procedures used to synchronize Content Type schemas (bundles and fields) changes for the data that resides into the structWSF instance:

  * structfieldstorage_synchronize_bundles_changes()
  * structfieldstorage_synchronize_fields_changes()

When loading an entity, we check if there are unexecuted rdfmapping changes, if there are, then we try to get data for these "old" fields to make sure we get the proper data from structWSF.